¿CON QUÉ IA?
A quién le sirve. Programadores y equipos técnicos que mantienen código propio o abierto y quieren una primera revisión de seguridad con IA; si no programas, te sirve para saber qué se puede pedir a tu equipo.
Qué hicieron
Nicholas Carlini, investigador de Anthropic, escribió un script corto que recorre todos los archivos del código del núcleo de Linux. Con cada archivo le dice a Claude Code que está en un concurso de seguridad (un CTF), que el fallo está en ese archivo, y le pide guardar en una carpeta el hallazgo más grave. Después, personas tenían que validar los resultados.
Cómo salió
Claude Opus 4.6 encontró varios fallos del núcleo explotables a distancia, entre ellos un desbordamiento de memoria en NFS de 2003. La fuente lista cinco vulnerabilidades ya corregidas o notificadas. Los modelos anteriores encontraban solo una pequeña parte.
Conviene saber
Validar a mano los hallazgos es el cuello de botella: Carlini tiene varios cientos de caídas sin revisar y no manda a los responsables avisos sin verificar, así que la mayoría sigue sin notificarse.
Qué necesitas
- Claude Code instalado en tu ordenador y una cuenta con acceso a él (plan de pago o clave de API).
- Una copia local del código que quieres revisar, que sea tuyo o de un proyecto abierto.
- Un entorno de pruebas aislado, como una máquina virtual, para comprobar los fallos sin riesgo.
- Alguien con conocimientos de seguridad que valide lo que salga.
- Paciencia: revisar archivo a archivo supone muchas llamadas al modelo y tarda.
Cómo hacerlo tú, paso a paso
- Descarga el código a una carpeta de tu ordenador y elige qué parte revisar. Empieza por una carpeta o módulo, no por todo el proyecto.
- Escribe un script corto que recorra los archivos de uno en uno y lance Claude Code sobre cada uno. Si no programas, pídele a Claude Code que te escriba el script.
- En cada pasada, dile que es un ejercicio de seguridad tipo concurso (un CTF), que en ese archivo hay un fallo, y que guarde el hallazgo más grave en una carpeta de resultados.
- Déjalo correr por tandas. Así vas mirando resultados sin esperar al final.
- Revisa cada hallazgo a mano en el entorno de pruebas. Descarta las falsas alarmas y quédate con lo que puedas reproducir.
- Si confirmas un fallo real, avisa en privado a los responsables del proyecto con la prueba. No lo publiques antes.
En mi copia local de [proyecto de código abierto o parte del núcleo] en [ruta], revisa el código de [carpeta o módulo] en busca de errores de memoria o de lógica que puedan ser vulnerabilidades de seguridad. Por cada sospecha, dame el archivo, la línea, por qué es un problema y cómo comprobarlo de forma segura en un entorno de pruebas. Habrás terminado cuando me entregues una lista ordenada por gravedad. No cambies nada ni informes de nada públicamente sin preguntarme.
Consejos
- Decide desde el principio quién va a validar los resultados. Es el cuello de botella: en el caso original quedaron varios cientos de hallazgos sin revisar.
- No mandes avisos sin verificar a los responsables de un proyecto. Les haces perder el tiempo y tú pierdes credibilidad.
- Revisa solo código tuyo o de proyectos abiertos, y prueba los fallos únicamente en un entorno aislado.
Preguntas frecuentes
¿Cuánto me va a costar?
La fuente no da cifras: se hace una llamada por archivo, así que cuanto más código, más uso del modelo. Prueba con una carpeta pequeña y mira cuánto consume antes de lanzar todo.
¿Sirve si no sé programar?
Para montarlo necesitas a alguien técnico. Y lo que más tiempo lleva es comprobar si cada aviso es real, algo que también tiene que hacer una persona con experiencia en seguridad.
Fuentes
La conversación en Hacker News, 3 de abril de 2026 ↗En el directorio desde el 3 de octubre de 2026.
@natecombsai en Substack