CRACI frente a un stack de SBOM propio

La respuesta corta

Un stack propio formado por Syft o Trivy, Grype, Dependency-Track, Cosign y Renovate no tiene coste de licencia, funciona en cualquier sitio y da a un equipo de plataforma capaz un control total. CRACI es un runner gestionado de GitHub Actions que registra lo que descargó cada build, controla a dónde puede conectarse, monitoriza lo distribuido y exporta la evidencia. La diferencia está menos en las funcionalidades y más en de dónde sale la SBOM y en quién mantiene las uniones. Si compila en GitLab, Jenkins o Windows, o si todo debe ejecutarse en su propia infraestructura, un stack propio es hoy la recomendación honesta.

Cómo es el stack

Una solución propia completa suele tener siete capas. Cada una es un proyecto real con su propio mantenimiento.

1. Generación. Syft, que genera una lista de materiales de software (SBOM) a partir de imágenes de contenedor y sistemas de archivos; Trivy; cdxgen, un proyecto de OWASP que crea BOM de CycloneDX a partir de código fuente e imágenes de contenedor; o Microsoft SBOM Tool, que escribe SPDX y espera en la línea de comandos una carpeta de salida del build, un nombre de paquete, una versión y un proveedor.
2. Cotejo. Grype escanea imágenes, sistemas de archivos y SBOM, con EPSS, KEV y puntuación de riesgo. OSV-Scanner coteja lockfiles, SBOM e imágenes de contenedor con OSV.dev.
3. Gestión. OWASP Dependency-Track ingiere SBOM en CycloneDX y las monitoriza a lo largo del tiempo. Su servidor de API necesita al menos 2 GB de RAM y 2 núcleos de CPU (se recomiendan 8 GB y 4 núcleos), y su documentación remite los despliegues de producción a Docker Compose con una base de datos independiente.
4. Firma. Cosign firma imágenes, blobs y atestaciones de SBOM, con firma sin claves mediante Fulcio y un registro de transparencia Rekor. GitHub artifact attestations se apoya en Sigstore y proporciona procedencia de SLSA v1.0 Build Level 2.
5. Actualizaciones. Renovate o Dependabot abren pull requests para mantener al día las dependencias.
6. Control de egress. StepSecurity Harden-Runner puede auditar o bloquear las conexiones salientes de los jobs de GitHub Actions. Su nivel Community es gratuito para repositorios públicos en runners alojados por GitHub; los repositorios privados y los runners autoalojados necesitan el nivel Enterprise. La alternativa son su propio proxy y sus propias reglas de firewall en torno a runners autoalojados.
7. Informes. Alguien convierte la salida de todo lo anterior en los documentos que necesitan un auditor, un cliente o un expediente técnico del CRA.

El coste está en las uniones

Elegir un generador es elegir sus puntos ciegos

Apunte varios generadores de SBOM al mismo repositorio y no se pondrán de acuerdo en lo que contiene. Cada uno lee un conjunto de archivos distinto y los resuelve de otra manera, de modo que la lista de componentes que obtiene depende tanto de la herramienta elegida como del proyecto. El campo de proveedor de la NTIA muestra lo mismo desde el otro lado: la mayoría de los generadores no tienen de dónde sacarlo, así que sale vacío contenga lo que contenga el repositorio.

Ninguna de estas herramientas está rota. Cada una toma una decisión distinta y documentada sobre qué cuenta como componente y en qué archivos confiar. Pero un stack propio hereda las decisiones que usted haya elegido, y el resto del pipeline (cotejo, monitorización, informes) solo puede ser tan completo como ese primer paso.

El pegamento es cosa suya

Cada herramienta tiene su propio ritmo de versiones, su base de datos de vulnerabilidades, su formato de salida y su configuración. Alguien fija las versiones, actualiza las bases de datos, mantiene parcheados Dependency-Track y su base de datos, rota las identidades de firma, decide qué SBOM va a cada sitio y se da cuenta cuando un paso empieza a producir menos sin avisar. Eso es trabajo de plataforma continuo, no una configuración de una sola vez.

Las herramientas también son dependencias

Las herramientas de seguridad se ejecutan dentro de sus builds con acceso a sus secretos, así que forman parte de su modelo de amenazas. En marzo de 2026, Aqua Security publicó un aviso que describía cómo se usaron credenciales comprometidas para publicar una versión maliciosa de Trivy y para reasignar con force-push la mayoría de las etiquetas de trivy-action a código que robaba credenciales durante unas 12 horas. Aqua lo documentó públicamente, y podría haberle ocurrido a cualquier proyecto muy utilizado. Muestra por qué importa el control de egress en el runner: una política de denegación por defecto limita a dónde puede enviar datos un paso comprometido, aunque no cubre todos los canales (el aviso describe también un mecanismo alternativo que creaba repositorios en la cuenta de GitHub de la víctima).

Cuándo conviene un stack propio

• Su CI no es GitHub Actions. CRACI solo es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta. Los equipos de GitLab, Jenkins y CircleCI pueden ejecutar todas las herramientas de código abierto anteriores.
• Compila en Windows o macOS. Los runners de CRACI son hoy Linux (x86-64 y ARM64); Windows y macOS están en la hoja de ruta.
• Todo debe ejecutarse en su infraestructura. CRACI ejecuta hoy runners gestionados en infraestructura europea, con runners alojados por el cliente en la hoja de ruta para Enterprise.
• Tiene un equipo de plataforma que quiere encargarse de ello. Si mantener el stack es una inversión deliberada y ya gestiona bien Dependency-Track, consérvelo.
• Necesita una SBOM para un cuestionario. Para una petición ocasional y de poca importancia, puede bastar con ejecutar un generador a mano.

Qué sustituye CRACI y qué no

CRACI cubre varias capas en un solo lugar, empezando por el build. Cambie runs-on a craci y las ejecuciones seguirán apareciendo en la interfaz de GitHub. Un proxy que entiende de paquetes registra lo que cada job descarga de fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga, y la evidencia de dependencias viaja con las cachés de CI. Cada job y cada caché reciben un estado de completitud: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

• Generación: CycloneDX y SPDX a partir del build registrado, dependencias transitivas incluidas.
• Monitorización: hallazgos agregados de todos los builds y repositorios, con las SBOM monitorizadas reevaluadas de forma continua.
• Procedencia: la API devuelve SBOM, trazas de red y procedencia. CRACI no firma la procedencia.
• Egress: política por job con 24 presets de fuentes de software integrados, validada antes de que empiece el job, que bloquea si falla y alerta de las infracciones.
• Exportación: SBOM en CycloneDX o SPDX, vulnerabilidades incluidas; sin exportación de informes.

No lo sustituye todo. Las listas de bloqueo de paquetes están en la hoja de ruta. Si necesita procedencia firmada, conserve Cosign o GitHub artifact attestations. Renovate o Dependabot siguen teniendo sentido para mantener al día todas las dependencias, no solo las vulnerables. Si su equipo de seguridad trabaja en Dependency-Track, la SBOM en CycloneDX se descarga mediante la API REST de CRACI y puede alimentarlo.

Un inventario de qué está desplegado y dónde

La vista de inventario de CRACI muestra exactamente qué versiones de software están desplegadas en qué productos, a escala global. Cuando aparece una nueva vulnerabilidad, puede ver qué productos ejecutan la versión afectada en lugar de reconstruirlo a partir de notas de versión y hojas de cálculo.

Para el Cyber Resilience Act

El CRA exige a los fabricantes identificar y documentar las vulnerabilidades y los componentes de los productos con elementos digitales, entre otras cosas elaborando una lista de materiales de software (anexo I, parte II). La notificación de vulnerabilidades explotadas activamente se aplica desde septiembre de 2026, con 24 horas para la primera notificación. Un stack propio puede cubrir eso, siempre que alguien se responsabilice del rastro de evidencia desde cada versión hasta su SBOM. CRACI automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro de software que las empresas necesitan para su proceso más amplio de cumplimiento del CRA, y envía en su nombre las notificaciones del CRA. Sea cual sea la vía que elija, decidir qué se está explotando activamente sigue correspondiendo a su equipo. Consulte el cumplimiento del CRA y la generación de SBOM durante el build.