Generación de SBOM, registrada durante el build
CRACI es una herramienta de generación de SBOM que registra lo que cada build de GitHub Actions descargó realmente, en lugar de escanear archivos después. Cada SBOM indica su grado de completitud.
En resumen: ejecute sus jobs de GitHub Actions en runners de CRACI y cada job obtendrá una SBOM de los paquetes que descargó, incluidas las dependencias transitivas y los paquetes restaurados desde cachés de CI, exportada en CycloneDX o SPDX. Cada SBOM incluye un estado de completitud y se monitoriza en busca de nuevas vulnerabilidades después del lanzamiento. Las herramientas de escaneo como Syft y Trivy reconstruyen una SBOM a partir de archivos; CRACI la registra a partir del build. Por qué son diferentes las SBOM generadas durante el build.
Registrada durante el build, no escaneada después
La mayoría de los generadores de SBOM leen archivos una vez terminado el build y reconstruyen lo que creen que se incluyó. CRACI genera la SBOM dentro de su propio runner de CI. Un proxy que entiende de paquetes observa el tráfico de cada job hacia las fuentes de paquetes, de modo que la SBOM recoge lo que el job descargó realmente, dependencias transitivas incluidas, y no lo que un manifiesto dice que debería necesitar. Para que exista el registro no hace falta lockfile, ni árbol de dependencias instalado, ni un paso de escaneo adicional.
Todas las capas de dependencias transitivas
La mayor parte de lo que descarga un build no es una dependencia directa. Es una dependencia de una dependencia, varias capas más abajo, y parte de ella ni siquiera aparece en un lockfile: binarios precompilados que descarga un script de build, paquetes restaurados desde una caché, paquetes del sistema operativo. CRACI registra cada paquete que descargó el job, a cualquier profundidad, de modo que las vulnerabilidades se cotejan con el árbol completo. En comparaciones directas con otras herramientas de SBOM, este registro más completo ha sacado a la luz vulnerabilidades que las otras herramientas no notificaron.
Los paquetes restaurados desde cachés de CI siguen en la SBOM
Las cachés son el punto donde el registro durante el build suele fallar: un paquete restaurado desde una caché nunca pasa por un registro de paquetes, así que un proxy por sí solo no lo vería. CRACI transporta la evidencia de dependencias junto con la caché, de modo que los paquetes restaurados desde una caché de CI siguen en la SBOM del job que los restauró.
Un estado de completitud para cada job
El seguimiento de vulnerabilidades solo puede cotejar los componentes que figuran en su SBOM. Un paquete que falta en la SBOM es una vulnerabilidad sobre la que nadie recibe alertas. Por eso, en lugar de presentar todas las SBOM como completas, CRACI indica la completitud de cada job y de cada caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Así sabe en qué SBOM puede confiar y cuáles conviene revisar de nuevo.
Los ecosistemas y formatos con los que trabaja
CRACI registra paquetes de fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga de Yocto y OpenEmbedded, y trata los mirrors de JFrog Artifactory para npm y PyPI como fuentes conocidas. La compatibilidad con Maven y Java está en la hoja de ruta. Las SBOM se exportan en CycloneDX y SPDX, dependencias transitivas incluidas, listas para compartir con clientes, socios y auditores.
Licencias declaradas en cada componente
Cada paquete registrado lleva su licencia declarada a la SBOM. Puede ver qué dependencias están sujetas a una licencia comercial o restrictiva de otro tipo antes de publicar, y las licencias copyleft se detectan antes de que acaben en su producto.
Procedencia a través de la API
La SBOM es una parte de lo que CRACI registra para cada job. La REST API pública devuelve SBOM, trazas de red y datos de procedencia, todo registrado a partir del mismo build.
Monitorizada después del lanzamiento
Una SBOM es la forma en que una empresa sabe qué contiene el software que distribuye, y cada vez más clientes y reguladores la exigen: el Cyber Resilience Act obliga a los fabricantes a elaborarla para los productos que se venden en la UE. CRACI reevalúa de forma continua las SBOM monitorizadas a medida que se publican nuevas vulnerabilidades, agrega los hallazgos de todos los builds y repositorios, y es compatible con VEX. Las SBOM que recibe de sus propios proveedores se monitorizan junto con sus builds.
Una SBOM registrada frente a una escaneada
Los escáneres son la herramienta adecuada para el software que usted no ha compilado. Para sus propios lanzamientos, esto es lo que cambia al registrar el build. Un escáner lee el lockfile o el resultado del build y deduce lo que se incluyó. CRACI ve el tráfico que entra en el build, de modo que las dependencias ocultas que descargan los hooks de instalación, los scripts de build y las imágenes base también acaban en la SBOM.
| Función | CRACI | Herramienta de SBOM basada en escáner |
|---|---|---|
| Cómo se obtiene la lista de componentes | Registrada a partir del tráfico de paquetes del propio build | Reconstruida a partir de archivos a posteriori |
| Necesita un lockfile o dependencias instaladas | No | Normalmente, una de las dos cosas |
| Paquetes restaurados desde cachés de CI | La evidencia viaja con la caché | Solo si los archivos están presentes al escanear |
| Estado de completitud por job | Cinco estados, por job y por caché | |
| Vínculo firmado entre artefacto y build | Sin procedencia firmada | Con un paso de firma independiente |
| Software que usted no ha compilado | Añada en su lugar la SBOM del proveedor | |
| Sistemas de CI | GitHub Actions hoy; otros sistemas de CI en la hoja de ruta | Funciona en cualquier CI |
- Incluido
- En parte
- No incluido
- En la hoja de ruta
¿Compara herramientas concretas? Consulte la comparativa de herramientas de SBOM para Syft, Trivy, cdxgen, la Microsoft SBOM Tool, Dependency-Track y otras. Para una visión más amplia, consulte la comparativa de herramientas de seguridad de la cadena de suministro de software.
SBOM basics: SPDX, CycloneDX and OpenVEX
Qué registra una SBOM, en qué se diferencian en la práctica los formatos SPDX y CycloneDX y qué aporta OpenVEX sobre si una vulnerabilidad afecta realmente a un producto.
Petteri Pulkkinen y Erika Marttinen en Kubernetes Community Days Helsinki 2026, 16:50 a 22:05 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Generación de SBOM: preguntas frecuentes
¿Qué es la generación de SBOM?
La generación de SBOM consiste en elaborar una lista de materiales de software (software bill of materials): una lista legible por máquina de los componentes y dependencias de un software. Puede hacerse a partir de los archivos fuente, durante el build o analizando un artefacto terminado, como una imagen de contenedor. CRACI genera la SBOM durante el build, a partir de lo que el build descargó realmente.
¿Cómo genera CRACI una SBOM?
Sus jobs de GitHub Actions se ejecutan en runners de CRACI. Mientras se ejecuta cada job, un proxy que entiende de paquetes observa su tráfico hacia las fuentes de paquetes y registra los paquetes que descarga, incluidas las dependencias transitivas y los paquetes restaurados desde cachés de CI. Cada job obtiene su propia SBOM con un estado de completitud.
¿Tengo que cambiar mis workflows?
Basta con cambiar runs-on a craci. CRACI sustituye el runner, no GitHub Actions, así que sus workflows y sus ejecuciones permanecen en GitHub.
¿Qué ecosistemas de paquetes registra CRACI?
Fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga de Yocto y OpenEmbedded. Los mirrors de JFrog Artifactory para npm y PyPI se tratan como fuentes conocidas. La compatibilidad con Maven y Java está en la hoja de ruta.
¿En qué formatos de SBOM puedo exportar?
CycloneDX y SPDX, con las dependencias transitivas y la licencia declarada de cada componente.
¿Qué significa el estado de completitud?
Complete significa que CRACI observó evidencia completa del job y que todas las cachés restauradas estaban completas. Complete with connections significa que el job también utilizó conexiones de red personalizadas que conviene revisar. Incomplete significa que alguna circunstancia podría haber dejado dependencias fuera. Unavailable significa que no se pudo evaluar la evidencia, y Not recorded significa que el job es anterior a la indicación de completitud.
¿Detecta CRACI vulnerabilidades en la SBOM?
Sí. CRACI reevalúa de forma continua las SBOM monitorizadas a medida que se publican nuevas vulnerabilidades, agrega los hallazgos de todos los builds y repositorios, y es compatible con VEX. Los equipos de seguridad priorizan lo que encuentra y lo envían a los equipos responsables de la corrección.
¿Puede CRACI generar una SBOM para software que no he compilado yo?
No. CRACI registra los builds que se ejecutan en sus runners. Para el software que compra, añada la SBOM del proveedor y CRACI la monitorizará junto con sus propios builds. Para una imagen de terceros que no ha compilado usted, un escáner es la opción práctica; consulte Comparativa de herramientas de SBOM.
Vea la SBOM de su propio build
Reserve una demo, ejecute uno de sus workflows de GitHub Actions en CRACI y vea lo que descargó realmente
Reservar una demo