Dónde se quedan cortas las herramientas de seguridad con IA y qué cubre la evidencia determinista del build

El argumento, en sus justos términos

Esto no es un alegato contra la IA en seguridad. Los modelos leen bien el código, explican un hallazgo y sugieren una corrección, y los equipos que los usan bien avanzan más rápido. El argumento es más acotado: para los registros que tienen que sostenerse más adelante, un modelo probabilístico no es la fuente principal adecuada. Eso incluye la SBOM que entrega a un regulador, la procedencia del artefacto que publicó y la respuesta a «¿nos afectó?».

Tres propiedades deciden si un registro se sostiene. Cada sección siguiente aborda una, con ejemplos y fuentes.

1. Reproducibilidad: preguntar dos veces y obtener la misma respuesta

Un registro de seguridad solo es útil si otra persona puede obtener la misma respuesta a partir de la misma entrada. Los modelos de lenguaje no lo garantizan, y los proveedores lo dicen.

• La documentación de Anthropic: «Incluso con la temperatura en 0, los resultados no serán totalmente deterministas y entradas idénticas pueden producir resultados distintos entre llamadas a la API».
• GitHub sobre Copilot Autofix: «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».
• Los investigadores que crearon el framework SecLLMHolmes probaron ocho LLM en 228 escenarios de código para IEEE S&P 2024. Señalan que los modelos «dan respuestas no deterministas» y que, «con solo cambiar nombres de funciones o de variables, o añadir funciones de biblioteca en el código fuente», PaLM2 y GPT-4 dieron respuestas incorrectas en el 26 % y el 17 % de los casos.

Ejemplo. Dos ingenieros preguntan al mismo asistente si un servicio está expuesto a un nuevo aviso de seguridad. Uno recibe «no»; el otro, «posiblemente, revise el árbol transitivo». Ninguna de las dos respuestas es un registro, y ninguna puede reproducirse ante un auditor seis meses después.

Un build registrado no tiene este problema, porque no se deduce nada. CRACI observa los paquetes que un job descarga de las fuentes de paquetes mientras se ejecuta, y la SBOM es un registro de esa observación.

2. Auditabilidad: demostrar cómo lo sabe

Las auditorías giran en torno a la pregunta «¿cómo lo sabe?». Un modelo puede dar una respuesta fluida, pero su explicación no es evidencia. La evaluación de SecLLMHolmes concluyó que los LLM ofrecen un «razonamiento incorrecto y poco fiel» sobre las vulnerabilidades que evalúan, de modo que un veredicto correcto puede venir acompañado de una explicación que no se sostiene.

Los estándares avanzan hacia registros que explican su propio origen. Los elementos mínimos de SBOM de 2026, publicados por CISA junto con la NSA, el FBI y socios internacionales, añaden SBOM Tool Name, SBOM Tool Version y SBOM Generation Context, que indica si la SBOM se generó «antes del build», durante el «build» o «después del build». El mismo documento advierte de que «las organizaciones pueden tener en cuenta los errores, ya se deban a las prácticas del autor de la SBOM o a la elección de herramientas inadecuadas, en sus decisiones de gestión del riesgo».

Ejemplo. Un cuestionario de un cliente pregunta cómo se generó su SBOM. «Un asistente leyó el repositorio y la redactó» aporta un contexto de generación, pero no uno que un revisor pueda comprobar. «Se registró dentro del runner de CI durante el build de la versión, y el estado de completitud del job es Complete» es algo que el revisor puede verificar contra el build.

3. Completitud: no se puede notificar lo que nunca se vio

Un modelo razona sobre lo que se le muestra. Si los archivos que lee no describen el software, la respuesta tampoco lo hará, y nada en el resultado lo indica. La guía de CISA de 2026 sitúa el listón en la decisión del destinatario: este «debería poder concluir que una vulnerabilidad recién notificada no le afecta si la SBOM no incluye el componente». Eso solo funciona si la ausencia en la lista significa ausencia en el build.

Ejemplo. El repositorio anthropics/claude-code en la v2.1.259 no tiene ningún manifiesto de dependencias ni lockfile de ningún tipo. El paquete npm publicado declara cero dependencias de ejecución y envuelve un binario nativo precompilado. Cualquier herramienta que lea el repositorio, sea de IA o no, apenas tiene nada que listar, mientras que el programa que se ejecuta es un binario compilado.

Ejemplo. Las herramientas de programación con IA también pueden introducir ellas mismas la laguna. GitHub advierte de que Copilot Autofix «puede sugerir dependencias inventadas publicadas con nombres estadísticamente probables». Un estudio de USENIX Security 2025 sobre 576.000 muestras de código generadas por 16 modelos encontró una tasa media de paquetes alucinados de al menos un 5,2 % en los modelos comerciales y un 21,7 % en los de código abierto, con 205.474 nombres únicos de paquetes alucinados.

Lo determinista es necesario, pero no suficiente

Una versión honesta de este argumento tiene que incluir el siguiente punto. Los generadores de SBOM son deterministas y, aun así, discrepan entre sí. Aplicados al mismo commit de expressjs/express, pueden devolver listas distintas, porque cada uno decide por su cuenta qué cuenta como componente y en qué archivos confiar. El repositorio no incluye lockfile, así que una herramienta que resuelve las dependencias a partir de uno no tiene ninguna de las dependencias de package.json que notificar.

Un escáner determinista reproduce la misma respuesta incompleta cada vez. La repetibilidad es necesaria, pero lo que cierra la brecha es la observación: registrar lo que el build descargó realmente e indicar cuándo el registro está incompleto. CRACI marca cada job y cada caché como Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

Un ejemplo práctico: delimitar el alcance de un nuevo aviso

Un supuesto: se publica un aviso de seguridad para una versión de un paquete npm muy utilizado. Según el Cyber Resilience Act, los fabricantes disponen de 24 horas para notificar a ENISA una vulnerabilidad explotada activamente, así que delimitar el alcance tiene que ser rápido y certero.

La vía de la IA primero

Pide a un asistente que revise sus repositorios. Lee manifiestos y lockfiles, y quizá un Dockerfile. No ve los paquetes restaurados desde una caché de CI, las herramientas descargadas por un paso del build ni las versiones resueltas durante la instalación en un repositorio sin lockfile. Si se le pregunta dos veces, puede responder de forma distinta. Su resumen es útil, pero no puede firmar su notificación basándose en él.

La vía del registro primero

CRACI agrega las vulnerabilidades de todos los builds y repositorios, limitadas a la rama por defecto a nivel de organización, y reevalúa las SBOM monitorizadas a medida que aparecen nuevas vulnerabilidades. La API devuelve la SBOM en CycloneDX de cada build, su traza de red y su procedencia. Si el registro de un job está incompleto, su estado de completitud le indica dónde revisar a mano. Puede seguir pidiendo a un modelo que resuma el resultado. Estará resumiendo un registro, no generándolo.

Con el registro, la pregunta «¿qué versiones publicadas incluían este paquete?» es una consulta, no una investigación.

Comparación directa

Ponga cada herramienta donde rinde mejor

Use la IA donde el criterio ayuda y una persona comprueba el resultado: revisión de código, explicación de un hallazgo, borrador de una corrección. Use registros deterministas del build donde el resultado tiene que reproducirse, auditarse o considerarse completo: SBOM, procedencia y delimitación de incidentes. CRACI automatiza una parte importante de esa evidencia de la cadena de suministro dentro de un proceso más amplio de cumplimiento del CRA. Por sí solo, no le hace cumplir la normativa.

Lea cómo se elabora el registro en la generación de SBOM durante el build, o empiece por lo que exige el CRA.