Una SBOM generada por IA es una conjetura sobre su build. Los reguladores piden un registro.

Por qué los equipos lo prueban

El atractivo es real. Pega un repositorio o un lockfile en un asistente de programación, pide CycloneDX y en segundos recibe un documento bien formado. Incluso puede rellenar campos que los escáneres suelen dejar vacíos. El campo del proveedor es el ejemplo habitual: la mayoría de los generadores no tienen de dónde sacarlo, así que sale en blanco. Un modelo al que se le pide un documento completo puede escribir algo en todos los campos.

Ese último punto es el problema en miniatura. Un escáner que no conoce al proveedor deja el campo en blanco. Un modelo que no lo conoce puede producir igualmente una respuesta verosímil. El documento parece más completo y es menos fiable.

Qué ve realmente el modelo

Un modelo que genera una SBOM trabaja a partir del texto que tiene delante: manifiestos, lockfiles, quizá un Dockerfile. No observa el build. Por eso no puede ver:

• qué versiones resolvió el gestor de paquetes cuando un repositorio no incluye lockfile,
• los paquetes restaurados desde una caché de CI,
• las herramientas, los paquetes del sistema operativo y los binarios que descarga directamente un paso del build,
• lo que entró en un binario compilado que se distribuye junto a un manifiesto casi vacío.

Dos repositorios muestran lo escasos que pueden ser los archivos. expressjs/express 5.2.1 no incluye lockfile, así que su package.json enumera las dependencias como rangos de versiones y las versiones reales se deciden durante la instalación. El repositorio anthropics/claude-code en v2.1.259 no tiene ningún manifiesto de dependencias ni lockfile, y su paquete npm publicado declara cero dependencias de runtime mientras envuelve un binario nativo precompilado. Un escáner determinista dirigido a ese repositorio no tiene nada que leer que describa el binario. Un modelo que recibe los mismos archivos tiene la misma falta de información, y más libertad para rellenar el hueco.

La alucinación es un modo de fallo documentado

Los modelos de lenguaje nombran paquetes que no existen. El caso mejor medido es la generación de código, no la redacción de SBOM, pero el fallo que muestra se aplica igual a una lista de componentes. Un estudio de USENIX Security 2025 generó 576.000 muestras de código con 16 modelos y 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. La propia documentación de GitHub sobre Copilot Autofix advierte de que puede sugerir dependencias inventadas, publicadas con nombres estadísticamente probables.

Los modelos tampoco dan dos veces la misma respuesta. La documentación de Anthropic indica que, incluso con la temperatura a 0, los resultados no son totalmente deterministas y entradas idénticas pueden producir salidas distintas entre llamadas a la API. Dos SBOM generadas a partir del mismo commit pueden diferir, y ninguna dice cuál es la correcta.

En una SBOM, una entrada alucinada no es una errata inofensiva. Un paquete que no existe, o la versión equivocada de uno que sí existe, envía la consulta de vulnerabilidades al lugar equivocado, y el resultado vuelve erróneo, pero con total convicción.

Qué esperan las normas que contenga una SBOM

Elementos mínimos de NTIA (2021)

La base de NTIA definió siete campos de datos: nombre del proveedor, nombre del componente, versión del componente, otros identificadores únicos, relación de dependencia, autor de los datos de la SBOM y marca de tiempo. Los acompañó de soporte para la automatización y un conjunto de prácticas y procesos. Cada campo describe un hecho sobre el software, no una opinión sobre él.

Elementos mínimos de CISA de 2026

El 29 de julio de 2026, CISA, la NSA, el FBI y socios internacionales publicaron unos elementos mínimos actualizados que sustituyen a la base de 2021. Varias novedades son difíciles de cumplir sin observar el build:

• SBOM Generation Context: la fase relativa del ciclo de vida del software y los datos disponibles cuando el autor generó la SBOM, con «before build», «build» y «after build» como ejemplos. Un modelo que lee un repositorio está, como mucho, en «before build».
• Component Hash Value: el resultado de aplicar un algoritmo hash criptográfico a un artefacto ejecutable del componente. Si el autor no dispone del artefacto, debe indicar que el valor es desconocido. Un modelo que nunca tocó el artefacto no puede producir un hash, solo texto con forma de hash.
• SBOM Tool Name and Version: hay que nombrar la herramienta utilizada para generar la SBOM.
• Coverage: una SBOM debe incluir información de todos los componentes que forman el software objetivo, incluidas las dependencias transitivas, sin una profundidad mínima.
• Explicitly identifying unknown information: el autor debe indicar explícitamente si la información es desconocida. Un valor inventado es lo contrario.

El Cyber Resilience Act de la UE

El CRA convierte la SBOM en una obligación legal para los fabricantes de productos con elementos digitales. El anexo I, parte II, les exige identificar y documentar las vulnerabilidades y los componentes de esos productos, entre otras cosas elaborando una lista de materiales de software en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de primer nivel de los productos. El anexo VII sitúa la SBOM en la documentación técnica, y una autoridad de vigilancia del mercado puede solicitarla para comprobar la conformidad con los requisitos esenciales.

Ninguno de estos textos prohíbe las herramientas de IA. Lo que piden son datos que describan el producto real y declaraciones honestas sobre lo que se desconoce. Una SBOM escrita por inferencia tiene dificultades con ambas cosas.

Cómo produce CRACI la SBOM

CRACI ejecuta sus jobs de GitHub Actions en sus propios runners. Usted cambia runs-on a craci, y las ejecuciones siguen apareciendo en GitHub. Mientras se ejecuta el job, un proxy que entiende de paquetes observa el tráfico hacia las fuentes de paquetes, de modo que la SBOM registra lo que el build descargó realmente, incluidas las dependencias transitivas. Las evidencias de dependencias viajan con las cachés de CI, así que un paquete restaurado desde una caché permanece en el registro.

• Ecosistemas: fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga.
• Completitud: cada job y caché se marca como Complete, Complete with connections, Incomplete, Unavailable o Not recorded, de modo que lo desconocido se indica en lugar de rellenarse.
• Formatos: CycloneDX y SPDX, con los metadatos de licencia declarada incluidos en la exportación.
• Procedencia: la API devuelve SBOM, trazas de red y procedencia.

CRACI automatiza una parte importante de la visibilidad y las evidencias de la cadena de suministro que necesita un proceso más amplio de cumplimiento del CRA. No hace que un producto cumpla por sí solo. La generación de SBOM durante el build explica los detalles, y nuestra introducción al CRA cubre el calendario.

Dónde sí ayuda la IA con las SBOM

Una vez que tiene una SBOM registrada, un modelo trabaja bien con ella: resume qué componentes conllevan riesgo, explica un aviso en lenguaje claro o redacta la documentación relacionada para que la revise una persona. La regla es sencilla. Deje que el build produzca el registro, y que el modelo lo lea.