A principios de este mes, ganamos una recompensa por bug de $2.5M: la recompensa más grande jamás recibida por un agente de IA. Era un bug en una blockchain importante, y puso en riesgo más de $100M en fondos. Encontramos el bug de forma totalmente autónoma usando V12, nuestro agente de seguridad con IA, y trabajamos en colaboración con el equipo para solucionar el problema.
V12 no es una herramienta de seguridad agéntica genérica. Encuentra regularmente bugs críticos como este, entre innumerables 0days (incluyendo LPEs de Linux, escape de QEMU, UXSS de Firefox, RCE bidireccional en Postgres y Redis). Eso es porque, aunque estamos construyendo un producto, nuestra misión principal es investigar y construir herramientas ofensivas de seguridad peligrosamente poderosas. Para hacerlo posible, hemos recaudado una ronda semilla de $10 millones liderada por Electric Capital, con la participación de ZachXBT, samczsun, Walden Yan y más.
Te animamos a que pruebes V12 tú mismo. Es de autoservicio, y al registrarte obtendrás $200 de uso gratuito durante los próximos siete días.
Parte 1: Lo que estamos haciendo
Nuestro objetivo es construir un arma nuclear cibernética. Eso significa construir algo que pueda encontrar todos los bugs de un sistema. Esto es particularmente interesante porque esa capacidad te permitiría explotar software que antes se consideraba seguro. Esto no había sido posible hasta ahora, pero la IA de frontera lo cambia.
No hacemos pentesting. El pentesting de caja negra que simula un atacante externo no nos interesa. Es un mercado saturado, y no queremos hacer otro producto que lance payloads XSS. Un pentest agéntico es excelente para encontrar algunos bugs, pero lo que queremos es algo que encuentre todos los bugs. Eso no es posible sin leer y entender el código. Necesitamos enfocarnos en la auditoría de código de caja blanca, que se parece más a la investigación de vulnerabilidades.
crédito del meme: LiveOverflow
Más concretamente, eso se ve como un sistema que puede razonar sobre el código y todas las abstracciones subyacentes, incluso crear otras nuevas (por ejemplo, máquinas extrañas). Queremos un sistema que no solo encuentre bugs, sino que pueda inventar clases de bugs completamente nuevas. Dicho esto, esta también ha sido el área de la seguridad que más se ha resistido a la automatización. Gran parte de la investigación de vulnerabilidades consiste en razonar cuidadosamente sobre el código y demostrarte a ti mismo “no, esto no puede tener bugs” o, alternativamente, preguntarte “espera, ¿y si…?”. Todo esto requiere inteligencia a nivel humano, algo que no ha sido posible escalar hasta ahora.
En resumen, lo que queremos es un sistema de IA que tome una base de código arbitrariamente grande y compleja, razone sobre cómo funciona realmente y luego use ese entendimiento para inventar—no solo descubrir—bugs y exploits.
Por supuesto, un sistema que pueda encontrar todos los bugs no es realmente posible; es el problema de la detención disfrazado. Es equivalente a demostrar que algo no tiene bugs, donde los exploits son contraejemplos. Puedes crear programas que sean arbitrariamente difíciles de explotar. Por ejemplo, un programa que es vulnerable si la conjetura de Collatz es falsa. Pero pretendemos empujar los límites y construir la aproximación más cercana que sea prácticamente posible.
Y nadie que nos guíe
Digamos que realmente construimos el arma nuclear cibernética. ¿Y ahora qué?
Ante una explosión de capacidades ofensivas, el mundo cambiará drásticamente. Sin embargo, es poco realista esperar que los desarrolladores—especialmente las empresas—se adapten de repente por sí solos. Las organizaciones maduras carecen de la visión o la experiencia para hacer el cambio correctamente. También necesitan soluciones: productos funcionales y bien diseñados, no solo “bolsas de herramientas”.
En cuanto a la capacidad de adaptación de las organizaciones: es fácil señalar los nuevos modelos de última generación y afirmar que la ciberseguridad está resuelta. Otra cosa es que los desarrolladores aprovechen significativamente los modelos para proteger su código. El desarrollador promedio todavía le pide a Claude o Codex que “revise mi PR en busca de bugs” y luego “OK, arregla estos”. ¡Eso no es ni de cerca suficiente! Los atacantes ya emplean harnesses y pipelines complejos y agresivos para encontrar bugs. Hay una asimetría aquí. Los defensores no tienen los recursos para crear estos pipelines, ni pueden amortizar el costo entre muchos objetivos de caza de bugs. Necesitan a alguien que aproveche, controle y despliegue estos modelos para desbloquear toda su capacidad.
Mientras tanto, la gente está ocupada. Están abrumados tratando de cumplir plazos y publicar funcionalidades de la hoja de ruta. No tienen tiempo para pensar en seguridad; quieren que alguien—o algo—venga y lo arregle por ellos. Debería integrarse directamente en su organización (por ejemplo, en su Slack), entender su flujo de trabajo (¿usas Github? ¿cómo se asignan los bugs? ¿qué usas para el seguimiento de incidencias? ¿qué agentes usas?) y sentirse adaptado a su contexto.
Por la misma razón, los defensores pierden a menos que tengan un producto que sea útil desde el primer momento. Debe ser completamente de autoservicio o venir con implementación de guante blanco. Debe tener el factor de forma correcto (¿una CLI? ¿un MCP? ¿un agente de Slack? ¿un bot de Github? ¿todos los anteriores?); debe sentirse bien (sin lag, que funcione en móvil, botones donde esperas, …); debe tener sentido (modelo de facturación no agresivo, control de acceso que funcione adecuadamente, selección lógica del alcance de auditoría, …). Hay un millón de cosas que hacer bien para que un producto así sea realmente adoptable.
En resumen: construir algo que tome programas arbitrariamente complejos, razone completamente sobre ellos y encuentre bugs novedosos. Luego empaquetar esa capacidad en un producto útil, y guiar de la mano a los desarrolladores para que realmente puedan usarlo y beneficiarse de él.
Parte 2: Cosas en las que creemos
OK, ¿cómo hacemos que esto realmente suceda? Cualquier plan de acción concreto es inútil (esta es una empresa en etapa semilla). Tiene más sentido exponer nuestros principios rectores y cómo predecimos que evolucionará el mundo.
Contra el “safetyismo”
Primero, creemos que la forma más eficiente de asegurar el software del mundo es darles a todos capacidades para encontrar bugs. No creemos en el “contáctanos” o “solicita acceso”. El estado final lógico es un mundo donde todos los bugs se encuentran y se corrigen. Restringir el acceso solo ralentiza este proceso. Para los mantenedores, adaptarse a un nuevo panorama de amenazas es incómodo pero inevitable, y creemos que el mejor enfoque es simplemente encontrar todos los bugs ahora. En la práctica, eso significa armar a los defensores con capacidades ofensivas para que puedan endurecer su propio código.
Para ser claros, queremos que el software sea seguro y confiable. Es irresponsable liberar capacidades ofensivas para las que el mundo no está preparado. Pero gran parte del “acceso controlado” o “verificación cibernética” que vemos últimamente es postureo y marketing. La gente usa las preocupaciones de seguridad como pretexto para no darle acceso a nadie—y en el proceso, no proteger a las personas a escala. Solo este año, V12 ha protegido a los usuarios con más de 6,000 revisiones de seguridad. No estamos en contra de la seguridad, estamos en contra del LARP de seguridad.
Divulgación abierta
Creemos en la divulgación abierta. La divulgación responsable será vista como una forma obsoleta de reportar y corregir bugs. Los embargos y la divulgación coordinada no tienen sentido en un mundo donde cualquiera con las herramientas adecuadas puede encontrar y weaponizar una vulnerabilidad con mínima intervención o experiencia humana. Vimos esto cuando encontramos y reportamos Fragnesia, Pintheft y DirtyDecrypt—0days de LPE en Linux que terminaron filtrándose antes de que los parches llegaran a los kernels principales. Cualquiera puede monitorear los commits públicos y recrear trivialmente un exploit weaponizado. La única solución real es eliminar por completo la brecha de parches. En la práctica, esto se ve como actualizaciones más frecuentes (y automáticas) y proveedores que envían parches el mismo día (¡hora!) en que se encuentra un bug. Particularmente, eso significa que los defensores necesitan capacidades extraordinarias de generación de PoCs y correcciones.
Los bug bounties están muertos
Los bug bounties en su forma actual estarán muertos, salvo los programas de adquisición de vulnerabilidades para bugs excepcionalmente valiosos. Todos los demás bugs serán extraídos por herramientas ofensivas cibernéticas como V12 antes de que el código se publique, es decir, antes de que los atacantes tengan la oportunidad de empezar a buscar.
Los mantenedores están cediendo bajo el peso de los envíos de IA a bug bounties. Muchos han anunciado que están terminando los bug bounties por completo. Ahora que los bugs se han vuelto más baratos que nunca, las únicas soluciones son: (1) dejar de preocuparse por la mayoría de los bugs o (2) dejar de distribuirlos. En el pasado, ambas eran insostenibles porque aunque prácticamente todo el código tiene fallas, razonar sobre todos los bugs posibles era prohibitivo en tiempo y costo. Pero ahora, creemos que no solo es posible sino inevitable.
La seguridad en cripto es interesante
Los proyectos cripto son objetivos interesantes y una cuña importante para nuestra empresa. Estamos obsesionados con encontrar todos los bugs, y el ámbito cripto es actualmente el lugar donde esto más importa. Más de $500M han sido robados en hacks solo este año. Si V12 puede tener éxito en el ámbito cripto—si podemos ganar en el “modo difícil”—entonces podemos ganar en cualquier lugar.
Con excepciones limitadas (¿cadena completa de iOS?), no hay bugs fuera del cripto que reclamen recompensas de siete u ocho cifras. Fuera del cripto, $50k todavía se considera una recompensa enorme. En el cripto, una vulnerabilidad crítica de pérdida de fondos vale cientos de millones de dólares si se explota. En general, nadie quiere tomarse la seguridad en serio, pero las empresas cripto están obligadas a hacerlo. Eso significa que al elegir productos de seguridad, seleccionan la capacidad de encontrar bugs por encima de los dashboards—para lo que V12 está optimizado. Mientras tanto, fuera del cripto, la seguridad todavía gira en torno a una cultura de cumplimiento, no de sustancia.
Todo el software es vulnerable, pero el mundo opera como si no fuera así. Esto solo funcionó hasta ahora porque los atacantes eran raros: la habilidad técnica era el cuello de botella. La IA elimina esa restricción. Ahora, si el software no es seguro, SERÁ explotado.
Por cierto, para disipar un concepto erróneo común: las bases de código cripto no son triviales en tamaño, complejidad o diversidad. Firedancer son 722k líneas de C altamente optimizado, Geth + Prysm son 1.1M líneas de Go, Zcash son 304k líneas de C++ y Python (solo Orchard son 44k líneas de circuitos y criptografía en Rust). Todos contienen máquinas virtuales, código de sistemas de bajo nivel y bases de datos distribuidas. Para contexto, Postgres y CPython rondan el ~1M de líneas.
Es hora de una seguridad real
El software del mundo siempre ha sido vulnerable, pero ahora es imposible ignorarlo. La web moderna depende de criptografía y navegadores seguros, los modelos de frontera dependen de TEEs para proteger los pesos, y las innovaciones en robótica y biología solo harán que la seguridad sea más importante. Básicamente, todo el código eventualmente se convierte en código de alta garantía.
No olvidemos la creciente complejidad de las cadenas de suministro de software. Mucho código en el que no pensamos será (o ya es) de alta garantía. OpenSSH ciertamente viene a la mente, pero ¿qué hay de todos los paquetes que olvidamos? Internet depende de software que nadie está mirando.
La forma en que se hace la seguridad actualmente no funcionará. Es una idea de último momento y se realiza con el mejor esfuerzo. Los equipos se enfocan en desarrollar funcionalidades y hacen que la seguridad sea responsabilidad de alguien más. La mayoría de los productos de seguridad parecen curitas que gestionan los síntomas de los bugs, no soluciones reales. Pero en un mundo con IA poderosa, si hay un solo bug, alguien lo va a encontrar y explotar.
En cambio, la seguridad necesita ser continua y exhaustiva: cada PR fusionado debe estar libre de vulnerabilidades. El camino para llegar allí no será fácil, y no tenemos todo resuelto. Nadie lo tiene. Pero el problema fundamental al que esto se reduce—encontrar bugs—es lo que nos ha obsesionado durante los últimos 10 años. Antes de V12, fundamos Zellic, una de las firmas de seguridad líderes del mundo, con más de 1500 revisiones de seguridad para más de 500 clientes altamente atacados (por ejemplo, exchanges de cripto, puentes, L1s, wallets, sistemas operativos de código abierto). Y antes de eso, fundamos perfect blue, el equipo de CTF #1 del mundo durante 3 años.
Cada persona del equipo de V12 proviene de CTFs o de investigación de vulnerabilidades. Mira lo que hemos reportado hasta ahora: múltiples LPEs de Linux, un escape de QEMU, RCEs gusanables en Redis y Postgresql (¡bidireccional!), en MariaDB y en Anydesk. Y lo que es aún más prometedor es que cualquier software nuevo que le lancemos a V12, los bugs no dejan de salir: el emulador Dolphin, el NAS de un empleado, el mensajero de Signal.
Reflexiones finales
Una buena ronda semilla te da lo mejor del mundo: la oportunidad de construir algo que amas con tus amigos.
Hemos soñado con este problema—encontrar todos los bugs automáticamente—desde que éramos adolescentes. Ahora la IA finalmente es lo suficientemente poderosa para que podamos intentarlo de verdad. Estamos emocionados. Si estamos en lo correcto, lo que estamos construyendo será peligrosamente capaz, y el mundo se adaptará a ello.
Queremos ser quienes lo hagan posible. Si V12 suena como algo de lo que te gustaría formar parte: únete a nosotros, ¡estamos contratando!
