- Chrome automatiza desde el descubrimiento de vulnerabilidades hasta su clasificación, corrección, distribución y aplicación de actualizaciones con agentes basados en Gemini, y corrigió 1.072 bugs de seguridad en Chrome 149 y 150, más que la suma de los 23 milestones anteriores
- El sistema de detección de vulnerabilidades combina varios modelos, una base de conocimiento con CVE e historial de Git de Chrome, SECURITY.md y un agente crítico separado, y funciona en un entorno con acceso estrictamente limitado a internet y al sistema local
- Se estima que la clasificación automática reduce cientos de horas de trabajo de desarrolladores al mes al eliminar spam y duplicados, reproducir problemas y recopilar stack traces, agregar metadatos como severidad y asignar responsables
- Para reducir la brecha de parcheo entre la publicación de una corrección y su explotación, se prueban lanzamientos de seguridad dos veces por semana, además de desarrollar parches dinámicos que reemplazan procesos hijos sin reiniciar y reinicio automático en macOS
- Más allá de corregir bugs individuales, Chrome aumenta la seguridad de memoria con MiraclePtr,
std::spany Rust, y previene la entrada de vulnerabilidades con revisiones de IA al momento de enviar código y actualizaciones automáticas de más de 2.300 dependencias externas
El ciclo de vida de los bugs de seguridad transformado por la IA
- Los LLM ampliaron la detección automática de vulnerabilidades más allá de la escala que puede manejarse solo con experiencia humana en seguridad, y Chrome usa IA para encontrar y corregir cientos de bugs de seguridad con mayor rapidez
- Mientras que los bugs funcionales comunes pueden causar problemas como que la UI se congele, los bugs de seguridad pueden usarse en exploits que permiten a un atacante leer datos personales o controlar una computadora sin que el usuario lo sepa
- Los bugs de seguridad se procesan en el orden de descubrimiento, clasificación, corrección, distribución de Chrome con la corrección incluida, reinicio del navegador y aplicación; el objetivo es acortar cada etapa tanto como sea posible
Expansión de la detección de vulnerabilidades
- El equipo de seguridad de Chrome desarrolló durante varios años tecnologías de detección basadas en LLM
- En 2023 desarrolló formas de aumentar el alcance y el rendimiento del fuzzing de seguridad
- En 2024 desarrolló Naptime con Project Zero para dar a los LLM herramientas especializadas de investigación de vulnerabilidades
- En 2025 desarrolló Big Sleep con DeepMind y Project Zero; este agente encontró bugs en el motor JavaScript V8 y en la pila gráfica
- El harness de agentes Gemini construido a comienzos de 2026 aumentó la eficiencia de detección y redujo los falsos positivos en una base de código más amplia de Chrome
- El bug de escape de sandbox encontrado podía permitir que un renderer comprometido engañara al navegador para leer archivos locales, y había permanecido en el código durante más de 13 años
- Al harness de detección se le agregaron las siguientes capacidades
- Interoperabilidad de modelos que aprovecha las fortalezas de modelos open-weight y modelos propietarios
- Una base de conocimiento que incluye todos los CVE existentes y todo el historial de Git de Chrome
- Guías para escribir SECURITY.md que comunican claramente los límites de confianza y el modelo de amenazas
- Un agente crítico que lee SECURITY.md en un contexto separado
- Escaneos repetidos de la base de código para reflejar la no determinación de los modelos y sus mejoras con el tiempo
- La IA analiza solo el código fuente almacenado en equipos bloqueados sin acceso a internet general
- Todas las solicitudes de red se interceptan y se aplican listas de permitidos basadas en la aplicación y el destino
- Los modelos no se ejecutan en modo sin restricciones, y se limitan los cambios al sistema por parte de subagentes y el acceso a archivos fuera de los directorios de código fuente designados
- La detección con IA no reemplaza las pruebas de seguridad existentes
- El fuzzing es especialmente eficaz para bugs que surgen de interacciones de largo alcance entre áreas de código separadas o de la combinación de varias operaciones aparentemente no relacionadas
- Los investigadores externos siguen recibiendo recompensas a través del Chrome Vulnerability Reward Program por encontrar vulnerabilidades difíciles y de alto impacto
- A comienzos de 2026 aumentaron los reportes de todo tipo, y en marzo se recibieron más reportes de bugs que en todo 2025
- En consecuencia, se modificó el VRP para aportar valor adicional a los hallazgos internos y enfocarse en reportes que el pipeline de procesamiento automático pueda aceptar fácilmente
Clasificación automática y corrección multiagente
- Antes, clasificar un reporte de seguridad tomaba de 5 minutos a más de 30 minutos y dependía principalmente de la experiencia humana; hoy se combinan sistemas basados en reglas e IA para aumentar el volumen procesado y la precisión
- La clasificación automática avanza en cuatro etapas
- Elimina spam y duplicados, y verifica si cumple los criterios de aceptación y si incluye una explicación clara de la vulnerabilidad de seguridad de Chrome
- Verifica la prueba de concepto y la reproducibilidad, prueba en el sistema operativo y la versión del navegador correspondientes, y adjunta información como stack traces
- Agrega el momento en que se introdujo el bug por primera vez y su severidad
- Las guías de severidad se aclararon para que puedan aplicarse automáticamente con facilidad
- Los desarrolladores pueden cambiar una calificación de severidad incorrecta y complementar información sobre límites de seguridad mediante SECURITY.md
- Asigna automáticamente el problema al componente y a los responsables correctos
- Aunque es difícil medirlo con precisión, se estima que la clasificación automática reduce cientos de horas de trabajo de desarrolladores al mes
- Para corregir vulnerabilidades se aplica un flujo de trabajo multiagente
- Un agente de corrección recibe el contexto específico de cada problema y genera varios parches candidatos
- Un agente crítico evalúa el candidato más adecuado y produce los artefactos necesarios para la revisión del desarrollador
- Ambos agentes realizan iteraciones similares a una revisión de código para comprobar el comportamiento funcional y el cumplimiento del estilo de Chromium y Google, así como de las convenciones del código local
- Un agente de escritura de pruebas verifica las pruebas en todas las plataformas y configuraciones compatibles con Chrome antes de la revisión del desarrollador, ahorrando hasta varias semanas
- Actualmente, los LLM generan correcciones candidatas para la mayoría de las vulnerabilidades
- En Chrome 149 y 150 se corrigieron 1.072 bugs de seguridad, superando la suma de los 23 milestones anteriores
- Big Sleep y CodeMender, desarrollados con DeepMind y Project Zero, están integrados en CI y revisan todos los CL cada 24 horas
- Solo en mayo se bloquearon más de 20 vulnerabilidades, incluidos problemas críticos S1+, antes de que llegaran a producción
Reducción de la brecha de parcheo y aplicación de actualizaciones
- El tramo en que un atacante puede hacer ingeniería inversa y explotar una corrección después de que el código corregido entra al repositorio open source público pero antes de distribuirse a los usuarios se llama brecha de parcheo, y corresponde a los ataques N-day
- Normalmente toma varias semanas que una corrección incorporada al árbol principal llegue al canal Stable usado por la mayoría de los usuarios
- Según la severidad, las correcciones se fusionan directamente en la rama de lanzamiento Stable actual y se siguen monitoreando nuevos conflictos o regresiones
- Al pasar los milestones principales de Chrome a un ciclo de 2 semanas, se ofrecen actualizaciones de seguridad cada semana
- Para responder a la velocidad de los ataques basados en IA, también se están probando lanzamientos de seguridad dos veces por semana
- Todos los bugs de seguridad que llegan a Stable se documentan públicamente, sin importar si fueron descubiertos interna o externamente
- Para eliminar cuellos de botella manuales y reducir el tiempo entre descubrimiento y publicación, se trabaja en generar automáticamente notas de versión y descripciones de CVE a partir de los parches
- Desde 2008, Chrome usa actualizaciones automáticas que descargan y preparan nuevos binarios en segundo plano y los aplican en el siguiente reinicio
- La clasificación, corrección, pruebas y distribución toman 1 o 2 días, pero la espera hasta que el usuario reinicie también puede contribuir de forma importante al riesgo de explotación N-day
- Reiniciar interrumpe el trabajo y requiere programarlo aparte, por lo que es fácil que los usuarios lo posterguen
- Se están desarrollando funciones para no trasladar al usuario la carga de reiniciar
- El parcheo dinámico aprovecha la arquitectura multiproceso de Chrome para reemplazar secuencialmente procesos hijos en segundo plano, como Renderer y GPU, por nuevos binarios, con el objetivo de eliminar en la mayoría de los casos el reinicio completo del navegador
- Se evalúan formas de guardar más estado localmente para poder restaurar la sesión incluso en situaciones complejas
- Se reinicia automáticamente cuando puede garantizarse la restauración completa de la sesión
- Chrome 150 detecta en macOS cuando todas las ventanas están cerradas pero la app permanece en segundo plano, y si hay una actualización pendiente reinicia automáticamente
- A largo plazo, el objetivo es un navegador siempre actualizado que combine parcheo dinámico continuo y reinicios automáticos en momentos de baja interrupción
- Las recomendaciones para administradores de TI empresariales son las siguientes
- Usar la política RelaunchNotification para aplicar medidas graduales, desde notificaciones hasta reinicio forzado después de un período definido
- En entornos sensibles donde deben validarse los cambios, usar Chrome Extended Stable Channel
- Con los paneles independientes del sistema operativo de Chrome Enterprise Core o Premium, rastrear las versiones de todos los navegadores y gestionar las actualizaciones de forma granular
Defensas en C++ y transición a Rust
- Chrome usa una estrategia doble: neutralizar en runtime las vulnerabilidades existentes de C++ y, a largo plazo, migrar hacia lenguajes con seguridad de memoria
- Como la mayor parte del código de Chromium está en C++, la toolchain y las mitigaciones en runtime son la primera línea de defensa inmediata
- Con una biblioteca estándar de plantillas reforzada y tecnologías de la familia MiraclePtr, se han reducido las vulnerabilidades Use-After-Free (UAF)
- La hoja de ruta de defensas en C++ se compone de tres ejes
- Expansión de MiraclePtr y MiracleObject
- MiraclePtr se expande a Skia, ANGLE, Dawn, iteradores de C++ y contenedores
std:: - MiracleObject busca neutralizar hasta el 90% de las vulnerabilidades UAF del hilo principal de GPU, intercambiando rendimiento local en runtime por seguridad temporal
- MiraclePtr se expande a Skia, ANGLE, Dawn, iteradores de C++ y contenedores
- Transición a
std::span- Sustituye estructuras existentes que usan punteros junto con tamaños por
std::span, verificado por el compilador, para eliminar accesos fuera de rango (OOB) - El 97% del código propio de Chrome compila sin problemas con advertencias estrictas de unsafe-buffer, y los requisitos se están ampliando también a Skia, ANGLE y Dawn
- Sustituye estructuras existentes que usan punteros junto con tamaños por
- Refuerzo de estructuras y asignación
- Se aplica checked math a los cálculos de asignación de memoria para bloquear rutas de integer overflow
- Un particionamiento adicional del heap que separa estrictamente tipos con punteros y tipos sin punteros dificulta la explotación de UAF
- Expansión de MiraclePtr y MiracleObject
- Se espera que las mitigaciones en runtime de C++ tengan rendimientos marginales decrecientes en los próximos años
- Las verificaciones en runtime tienen mayor costo que las garantías en tiempo de compilación, y aun los binarios C++ fuertemente mitigados necesitan sandboxes estrictos que limitan el rendimiento para cumplir con la Rule of Two
- A largo plazo se impulsa la transición a Rust
- Flywheel de Rust: construir un SDK central que ofrezca directamente en Rust APIs y herramientas basadas en Chromium, para que pueda elegirse de forma cotidiana en nuevos componentes
- Eliminación de zonas densas en bugs: reemplazar estratégicamente código que históricamente tuvo alta densidad de bugs, como parsers de datos complejos, códecs de imagen y la pila de fuentes
- Modularización de alto privilegio: escribir nuevos módulos en Rust para ejecutar funciones complejas incluso en áreas de alto privilegio, como el proceso del navegador, sin el costo de rendimiento del sandbox
- También se evalúa implementar la UI de nivel superior del navegador con HTML, CSS y TypeScript para reducir aún más la dependencia de frameworks C++ existentes
Bloquear vulnerabilidades antes de enviar código
- Como solo escanear periódicamente toda la base de código dificulta seguir el rápido ritmo de desarrollo de Chrome, las revisiones con IA se ubican cerca del momento de envío del código
- El modelo de defensa de CI y la cola de commits (CQ) revisa automáticamente los cambios
- Propone correcciones de transición a
std::span - Señala punteros colgantes
- Impone seguridad en operaciones numéricas
- Propone correcciones de transición a
- Código que es seguro de forma independiente puede convertirse en un problema de seguridad potencialmente grave cuando se combina con un pequeño cambio lógico en otra ubicación
- El análisis semántico continuo con LLM dentro de la CQ encuentra interacciones sutiles o complejas que el análisis estático tradicional pasa por alto, y las bloquea antes de que el código entre al árbol
Ecosistema open source y dependencias externas
- La seguridad web depende no solo de Chrome, sino también de los proyectos open source y de la capacidad de respuesta de sus mantenedores
- Google donó 12,5 millones de dólares junto con otros participantes al proyecto Alpha-Omega, para que los mantenedores cuenten con herramientas y apoyo para responder rápidamente a reportes de vulnerabilidades
- Participó como miembro fundador del proyecto Akrites, cuyo objetivo es ofrecer una ventanilla central de reportes de vulnerabilidades y un equipo de respuesta a incidentes de seguridad para reducir la carga de los mantenedores upstream
- Chromium y proyectos relacionados como V8, BoringSSL, Skia, ANGLE y Dawn tienen más de 2.300 dependencias externas
- De ellas, unas 1.700 se distribuyen a usuarios a través de productos diversos, como dispositivos Android, plataformas de edge computing y stacks de grandes empresas cloud
- El pipeline de revisión automática de vulnerabilidades recopila feeds internos de Google y datos de la NVD del gobierno de Estados Unidos y de OSV, centrada en open source
- Como el monitoreo posterior puede dejar una brecha de riesgo, se empezó a migrar todas las dependencias externas de Chrome hacia un pipeline de actualización automática que las actualiza proactivamente a las versiones upstream más recientes
- Durante la automatización se usan señales de seguridad de proyectos como GOSSIP para reflejar también otros riesgos del ecosistema open source externo
Un navegador protegido de forma continua
- Que aumente la cantidad de bugs encontrados y corregidos con LLM no es un fracaso; cada bug corregido reduce un punto de apoyo que un atacante podría usar
- Encontrar y corregir no basta: hay que distribuir la corrección y aplicarla en el entorno del usuario antes de que un atacante la explote
- Combinando lanzamientos más rápidos, parcheo dinámico, reinicios automáticos en momentos de baja interrupción y defensas estructurales, Chrome apunta a estar protegido de forma continua sin molestar a los usuarios
1 comentarios
Opiniones en Hacker News
Últimamente he usado mucho la IA para optimización de rendimiento mientras he estado ocupado con el trabajo, pero casi no me sirvió para definir la dirección de alto nivel. Aunque señalaba partes sospechosas en consultas SQL, casi no había diferencia de rendimiento antes y después, me hizo perder tiempo con sugerencias inútiles, y hasta tuve que lidiar con gente que lanzaba salidas de IA sin procesar como si fueran contribuciones significativas
Aun así, implementar cambios que yo mismo había encontrado o mover joins a CTE se volvió mucho más fácil
Aunque le repitas a la herramienta de IA “sé concisa”, “responde solo la pregunta”, “no des información no solicitada”, sigue produciendo más de lo necesario, y parece un intento sutil de consumir más tokens
Solo con el texto del código no puede saber el tamaño de caché, el volumen de la base de datos ni la latencia de red, así que hay que darle ese contexto para obtener mejores resultados
Un dato clave es que en el Pwn2Own de Berlín de mayo pasado Firefox no pagó absolutamente nada en premios. Desde 2007 se habían pagado premios en todos los eventos, así que no haber tenido ni una sola vulnerabilidad confirmada parece indicar que las vulnerabilidades fáciles ya casi desaparecieron y que este modelo tiene cierta utilidad
Puedo creer que se puedan corregir muchos errores, pero me da curiosidad el proceso real. También es posible que Google publicara un blog y que durante varios sprints se impulsara la corrección de errores para que los managers pudieran mostrar hacia arriba resultados de adopción de IA, haciendo que los equipos trabajaran mucho más de lo normal
El rendimiento de un LLM depende de la estructura iterativa en la que se ejecuta, y esa estructura depende de la calidad de los verificadores, así que no hace falta asumir una exhibición de resultados por parte de los managers para explicarlo
En vez de dejar que la IA trabaje sin control, hay que usarla como herramienta de aceleración, pero los críticos parecen confundir ambas cosas. Es una falacia del hombre de paja parecida a enojarse con Excel porque el retorno de inversión es malo, así que más que seguir discutiendo quisiera compartir en silencio formas de usarla bien con gente que realmente quiere usarla de manera eficiente
Si la dejas sola, el resultado empeora tras unas cuantas iteraciones; si la guías con detalle, sí aporta valor, pero ese esfuerzo termina costando casi lo mismo que escribir el código directamente, sobre todo cuando hay trabajo repetitivo
No se puede saber cuántas de las correcciones automáticas se revirtieron, cuántos bugs nuevos crearon ni cuál es la tasa de falsos positivos del agente de detección. La publicación solo muestra cifras exitosas y no dice nada sobre lo que puede salir mal
Incluso si al corregir 10 bugs se crean 2 nuevos, mientras no sean fallas graves explotables por sí solas, el balance neto sigue siendo muy positivo. Los ataques contra navegadores exigen cadenas de vulnerabilidades enlazadas cada vez más largas, así que es difícil ignorar la ventaja de usar IA para encontrar bugs potenciales
https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....
Me preocupa que, en el futuro, Google concluya que Chromium ya no necesita una búsqueda colectiva de bugs abierta al público y deje de desarrollarlo de forma abierta. Si eso pasa, las variantes actuales basadas en Chromium se volverían en la práctica forks de la última versión pública y, al no tener los mismos recursos de mantenimiento que Chrome con apoyo de Gemini, la dificultad para mantener cada fork podría divergir mucho
Las críticas a la IA suelen centrarse en una categoría estrecha: que genere código a ciegas es malo, y eso se puede conceder fácilmente. Pero del otro lado están las pruebas adversariales, la validación de supuestos de los desarrolladores, las sugerencias de refactorización, las herramientas pequeñas de desarrollo, la programación con guía y el rastreo de dependencias y comportamiento en bases de código grandes, donde sí puede ser de gran ayuda
Con demasiada facilidad se mezclan las críticas al código generado a ciegas con todos esos otros usos
La clave, para empezar, es cuántos de estos bugs surgieron de código escrito por un LLM. Crear 100 veces más bugs y corregir 100 veces más bugs no es algo de lo que presumir
Como es un proyecto de código abierto, incluso se puede comprobar directamente si realmente fueron bugs creados por un LLM
Me pregunto si también corrigieron los bugs de rastreo de comportamiento con los que Chrome intenta rastrear a los usuarios, haga lo que haga y esté donde esté