Las herramientas de seguridad con IA leen su código. Algo tiene que seguir registrando su build.

Probablemente su equipo ya está incorporando la IA a la seguridad

La mayoría de los equipos de ingeniería tienen ya al menos una herramienta de IA en el circuito de seguridad. Un modelo revisa las pull requests. Otro sugiere correcciones para las alertas del análisis estático. Un tercero clasifica los hallazgos de los escáneres en «revise esto» y «probablemente ruido». Estas herramientas ahorran tiempo de verdad, y nada de lo que dice esta página va en su contra.

La pregunta útil es qué tareas deberían asumir y qué tareas necesitan un registro que salga igual cada vez. La pregunta complementaria es qué están leyendo sus herramientas de IA cuando toman una decisión sobre sus dependencias.

Lo que las herramientas de seguridad con IA hacen bien

• Revisión de código con IA. GitHub Copilot code review deja comentarios en lenguaje natural y sugerencias de código en las pull requests, y puede seguir instrucciones específicas de cada repositorio. Se le da bien el trabajo de lectura que un revisor con prisa se salta.
• Correcciones con IA. GitHub Copilot Autofix «genera automáticamente sugerencias de cambios de código para las alertas de CodeQL detectadas en pull requests y en la rama por defecto». El desarrollador recibe un parche propuesto junto a la alerta en lugar de un enlace a una página de CWE.
• Triaje con IA. Las funciones de IA de Semgrep realizan el autotriaje de los hallazgos de Semgrep Code y sugieren correcciones. Semgrep documenta que su filtrado de ruido tiene «más de un 95 % de precisión al clasificar hallazgos de Semgrep Code como falsos positivos».

Fíjese en el patrón de los dos últimos. Copilot Autofix trabaja sobre alertas de CodeQL. El triaje de Semgrep trabaja sobre hallazgos del motor basado en reglas de Semgrep. La IA añade criterio sobre un resultado determinista. No genera ella misma los hallazgos de partida.

Lo que dicen los proveedores sobre los límites

Las declaraciones más claras sobre dónde se detienen las herramientas de IA proceden de los propios proveedores, lo que les honra.

• Sobre la revisión de código, GitHub escribe que «es posible que Copilot no identifique todos los problemas presentes en el código» y que «tiene riesgo de alucinación», es decir, de señalar problemas que no existen.
• Sobre Autofix, GitHub escribe que «utiliza un modelo generativo que no es determinista. Incluso con la misma alerta y el mismo código, podría no producir una sugerencia viable, o la sugerencia podría variar entre intentos».
• También sobre Autofix: «El sistema no sabe qué versiones de las dependencias son compatibles o seguras, y puede sugerir dependencias inventadas publicadas con nombres estadísticamente probables».

Nada de esto hace que las herramientas sean menos útiles. Define su función: producen sugerencias para que una persona las compruebe. Esa es una función distinta de la de producir el registro con el que esa persona las comprueba.

Dos capas, dos funciones

CRACI se sitúa en la capa del registro. Sustituye el runner de GitHub Actions (usted cambia runs-on a craci), y un proxy que entiende de paquetes observa el tráfico del build hacia las fuentes de paquetes mientras se ejecuta el job. El resultado es una SBOM de lo que el job descargó realmente, un estado de completitud para cada job y cada caché, y una traza de red. La API devuelve SBOM, trazas de red y datos de procedencia.

Dónde se necesita visibilidad determinista

«¿Nos afecta?»

Cuando se publica un nuevo aviso de seguridad, la primera pregunta es si alguno de sus builds incluyó la versión afectada. Los elementos mínimos de SBOM de 2026 de CISA formulan el requisito con claridad: el destinatario de una SBOM «debería poder concluir que una vulnerabilidad recién notificada no le afecta si la SBOM no incluye el componente». Esa conclusión solo es válida si la lista está completa. Un modelo puede ayudarle a leer la respuesta. No debería ser lo que decide qué había en el build.

CRACI agrega las vulnerabilidades de todos los builds y repositorios y reevalúa las SBOM monitorizadas a medida que se publican nuevas vulnerabilidades, de modo que la pregunta se responde a partir de lo que se registró.

Dependencias que añadió una IA

Los asistentes de programación con IA añaden dependencias, y la investigación demuestra que a veces nombran paquetes que no existen. Un estudio presentado en USENIX Security 2025 generó 576.000 muestras de código con 16 modelos y concluyó que la proporción media de paquetes alucinados era de al menos un 5,2 % en los modelos comerciales y un 21,7 % en los modelos de código abierto. Un nombre que no existe hoy puede registrarse mañana. Sea quien sea, persona o herramienta, quien haya añadido una dependencia, CRACI registra el paquete que el build descargó realmente, y las políticas de egress de red pueden limitar un job a las fuentes de paquetes que usted apruebe.

Auditorías y preguntas de los clientes

Un auditor o el equipo de seguridad de un cliente le preguntará cómo sabe lo que se publicó. «Lo dijo el modelo» es una respuesta débil. «Aquí está la SBOM registrada durante el build de la versión, su estado de completitud y la traza de red de ese job» es una respuesta sólida. Las SBOM se exportan en CycloneDX o SPDX, vulnerabilidades incluidas, y la API devuelve SBOM, trazas de red y datos de procedencia.

Respuestas repetibles

Algunas preguntas necesitan la misma respuesta, pregunte quien pregunte y cuando sea. ¿Qué paquetes descargó la versión del martes pasado? Un modelo generativo puede formular bien esa respuesta, pero, según sus propios proveedores, puede formularla de forma distinta cada vez. Un build registrado da una única respuesta.

Cómo encajan las dos

El patrón que funciona es el que ya usan Copilot Autofix y Semgrep: datos deterministas debajo y criterio de IA encima.

1. Deje que la revisión de código y las correcciones con IA trabajen sobre las pull requests, con una persona aprobando cada cambio.
2. Deje que CRACI registre lo que descargó cada build e indique si ese registro está completo.
3. Cuando quiera ayuda de la IA con el riesgo de las dependencias, entregue al modelo la SBOM registrada. La API REST pública de CRACI devuelve la SBOM en CycloneDX, la traza de red del job y la procedencia del artefacto.
4. Conserve como evidencia la SBOM registrada, no el resumen que el modelo hace de ella.

Si su equipo escribe buena parte de su código con asistentes de IA, nuestra página sobre seguridad del desarrollo con IA trata esa situación, y la generación de SBOM durante el build explica cómo se elabora el registro.