CRACI frente a Dependency-Track

Qué hace bien Dependency-Track

OWASP Dependency-Track es una opción sólida para el análisis de componentes. Es de código abierto con licencia Apache 2.0, sigue el uso de los componentes en cada versión de cada aplicación de su cartera y obtiene inteligencia de vulnerabilidades de varias fuentes, incluidas la National Vulnerability Database y GitHub Advisories. Su motor de políticas cubre reglas de seguridad, de licencias y operativas, y consume y produce documentos VEX de CycloneDX. Su diseño centrado en la API encaja con CI/CD: los pipelines suben las SBOM a /api/v1/bom.

Los equipos de sectores regulados lo aprecian porque es transparente, autoalojado y está construido en torno a un formato estándar. Su punto débil no es el análisis, sino lo que entra en él.

El análisis depende de lo que recibe

Dependency-Track consume SBOM; no las genera. Cada hallazgo, infracción de políticas y vista de cartera depende de la SBOM que envía su pipeline. Si a la SBOM le falta una dependencia, Dependency-Track no puede señalarla. Si dos generadores discrepan, Dependency-Track muestra la que usted haya subido.

En la práctica, los generadores de SBOM discrepan mucho, y los motivos están en su propia documentación:

• Sin terreno común. Cada generador decide por su cuenta qué cuenta como componente y en qué archivos confiar, así que dos de ellos aplicados al mismo repositorio devuelven listas que se solapan pero son distintas.
• Se les escapa lo evidente. Una herramienta que resuelve dependencias a partir de lockfiles no tiene nada que resolver en un repositorio que no incluye ninguno, como ocurre con express 5.2.1. Aun así puede devolver una lista, compuesta por cualquier otra cosa que reconozca, como GitHub Actions y archivos de workflow.
• Variaciones por configuración. Syft elige sus catalogadores según el tipo de escaneo, así que un solo flag cambia lo que la misma herramienta en la misma versión indica sobre el mismo checkout.
• Sin manifiesto, no hay SBOM. Un repositorio sin ningún manifiesto de dependencias no da a un escáner basado en archivos nada con lo que trabajar, y lo que devuelve cada herramienta dice entonces más de la herramienta que del proyecto.
• Metadatos escasos. La mayoría de los generadores no tienen de dónde sacar el campo de proveedor de la NTIA, así que sale vacío sea cual sea el contenido del repositorio.

CRACI no se puede comparar de esta manera. Registra builds en lugar de escanear un directorio, así que no se puede ejecutar del mismo modo. No se trata de que ninguna de estas herramientas sea mala. Se trata de que un escaneo estático de un repositorio es una estimación de lo que usará un build, y la estimación varía con la herramienta, su configuración y los archivos presentes.

Qué cambia CRACI en el origen

La SBOM procede del build

CRACI es un runner compatible con GitHub Actions. Usted cambia runs-on a craci y sus jobs se ejecutan en CRACI en máquinas virtuales aisladas. Durante cada job, un proxy que entiende de paquetes registra el tráfico hacia las fuentes de paquetes: fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga. Las evidencias de dependencias viajan con las cachés de CI, así que un paquete restaurado desde una caché sigue en el registro. La SBOM, en CycloneDX o SPDX, incluye todas las dependencias transitivas que el build utilizó realmente.

Le avisa cuando está incompleta

Cada SBOM de CRACI lleva un estado de completitud por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Usted sabe si cada SBOM es un registro completo o tiene un hueco. Eso importa cuando un auditor pregunta cómo sabe que su inventario está completo.

Registra la SBOM dentro del build

CRACI genera la SBOM dentro de su propio runner, a partir de lo que descargó el job. La API devuelve SBOM, trazas de red y procedencia.

Controla a qué puede acceder el build

Como CRACI ejecuta el job, puede aplicar una política de egress de red: de denegación o de permiso por defecto, con 24 presets integrados de fuentes de software y fuentes personalizadas tipadas. Las políticas se validan antes de que empiece el job y bloquean si fallan. Dependency-Track puede indicarle a posteriori que un componente es de riesgo; una política de egress limita de entrada de qué fuentes puede descargar un build.

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 surge 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.

Sustituir Dependency-Track por CRACI

CRACI cubre las dos mitades del trabajo que antes requería un generador y Dependency-Track. Produce la SBOM en el build, sigue reevaluando las SBOM monitorizadas a medida que se publican nuevas vulnerabilidades, agrega los hallazgos de todos los builds y repositorios, y permite a los equipos de seguridad hacer su triaje y enviar cada uno al equipo responsable de la corrección. No hay ningún paso de subida que mantener ni ningún servidor que gestionar.

Tenga claro a qué renuncia. El motor de políticas de Dependency-Track es maduro. CRACI tiene controles de políticas que bloquean builds y política de licencias, mientras que los comentarios y las alertas por umbral están en la hoja de ruta. Dependency-Track es además de código abierto y autoalojado, mientras que CRACI es hoy un servicio gestionado, con runners alojados por el cliente en la hoja de ruta para Enterprise. Si esto le importa más que la calidad del inventario, conserve Dependency-Track.

Por qué importa en los sectores regulados

Según el Cyber Resilience Act de la UE, los fabricantes deben saber qué contiene cada versión de producto y gestionar sus vulnerabilidades, con obligaciones de notificación de las vulnerabilidades explotadas activamente a partir de septiembre de 2026. Una vulnerabilidad que no puede ver porque a su SBOM le faltaba el componente sigue siendo su vulnerabilidad.

CRACI automatiza una parte importante de la visibilidad y las evidencias de la cadena de suministro de software que las empresas necesitan para su proceso más amplio de cumplimiento del CRA, y exporta SBOM en CycloneDX o SPDX, con vulnerabilidades incluidas. El inventario y la monitorización proceden del mismo registro de aquello con lo que se compiló cada versión. Consulte cumplimiento del CRA, IoT industrial y telecomunicaciones.