CRACI frente a Kusari

La respuesta corta

Kusari es una plataforma de seguridad de la cadena de suministro de software del equipo que cocreó GUAC, el grafo de código abierto para metadatos de la cadena de suministro. Crea un grafo de conocimiento actualizado de forma continua a partir de su código fuente, sus SBOM, sus documentos VEX y la salida de sus escáneres actuales, clasifica lo que es explotable, revisa pull requests y abre correcciones. CRACI es un runner de GitHub Actions. Registra lo que incorpora cada build mientras se ejecuta, controla a qué puede acceder el build y sigue monitorizando lo distribuido. Cualquier grafo refleja las SBOM que recibe; CRACI genera las SBOM desde el propio build. Ambos compiten por el mismo presupuesto de cadena de suministro. Para el software que usted mismo compila, CRACI cubre el CI, la SBOM y el seguimiento de vulnerabilidades en un solo producto.

De un vistazo

Kusari y GUAC, con precisión

GUAC (Graph for Understanding Artifact Composition) es un proyecto en incubación de OpenSSF, dentro del grupo de trabajo Supply Chain Integrity, con licencia Apache 2.0. Agrega metadatos de seguridad de software en una base de datos de grafos. Entre sus entradas documentadas están las SBOM en CycloneDX y SPDX, las atestaciones in-toto y SLSA, los documentos OpenVEX y CSAF, los resultados de OpenSSF Scorecard y los datos de OSV y deps.dev. GUAC agrega metadatos que producen otras herramientas; no ejecuta builds.

Los cofundadores de Kusari cocrearon GUAC con Google, y un cofundador de Kusari es el principal mantenedor de GUAC. Kusari afirma que utiliza y cuida GUAC, SLSA, OpenSSF Scorecard, ClearlyDefined y otros proyectos de código abierto en sus productos comerciales. GUAC también tiene otros colaboradores, como Google, Red Hat, Purdue University y Citi. Kusari es la plataforma comercial; GUAC es el proyecto de la comunidad.

Lo que Kusari hace bien

Un grafo construido sobre estándares abiertos. La plataforma de Kusari ingiere código fuente, artefactos de build, SBOM en CycloneDX y SPDX, VEX y la salida de escáneres existentes, incluidos los resultados de Snyk, Black Duck, Prisma Cloud, Dependabot y GitHub Advanced Security. Mapea las dependencias directas y transitivas con su procedencia y linaje, y muestra el radio de impacto de una nueva vulnerabilidad en todo su entorno.

Menos hallazgos y mejores. Los análisis de alcanzabilidad y explotabilidad buscan pruebas de que el código vulnerable se invoca realmente, de modo que la cola contiene lo que importa. AutoFix genera pull requests de corrección y las valida antes de que lleguen a su repositorio.

Comprobaciones en la pull request. Kusari Inspector revisa cada pull request en GitHub o GitLab en busca de vulnerabilidades transitivas, secretos filtrados, paquetes maliciosos y de typosquatting, riesgo de licencias, dependencias al final de su vida útil, workflows inseguros de GitHub Actions y debilidades comunes del código. Kusari afirma que Inspector se instala gratis, sin necesidad de hablar con ventas.

Estándares y marcos. Kusari produce SBOM y atestaciones en formatos SPDX, CycloneDX e in-toto, e indica compatibilidad con marcos como el CRA de la UE, FDA 524B, SSDF, IEC 62443 y DORA. Su herramienta de subida funciona en GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket Pipelines y TeamCity.

En qué se diferencia CRACI

Kusari describe su grafo como construido a partir del código fuente y los sistemas de build a medida que se crea el software, en lugar de reconstruido a partir de binarios terminados. Es la intuición correcta, y es también donde los dos productos se separan. Las SBOM de Kusari salen de un generador: su documentación describe generarlas con waybill, su kit de herramientas de SBOM de código abierto, cuando se fusionan las pull requests, o bien traer su propia herramienta. Un generador lee lockfiles, manifiestos, cachés e imágenes. CRACI no lee los archivos del build para inferir qué utilizó. Es la máquina en la que se ejecuta el build.

Un registro, no una reconstrucción

Con un cambio de una línea en runs-on, su workflow se ejecuta en CRACI. Un proxy que entiende de paquetes registra lo que cada job descarga de las fuentes de paquetes, y los paquetes restaurados desde cachés de CI se arrastran al registro. Cada SBOM indica su grado de completitud, por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. La monitorización parte de lo que el build descargó realmente, y sabe dónde están las lagunas.

Control durante el build

Un grafo le ayuda a encontrar lo afectado a posteriori. Una política de egress en el runner decide, mientras se ejecuta el job, a qué hosts puede acceder. Las políticas de CRACI son de denegación por defecto o de permiso por defecto, con 24 presets de fuentes de software integrados, se validan antes de que empiece el job y, si fallan, bloquean.

Procedencia y monitorización a partir del mismo registro

La API devuelve SBOM, trazas de red y procedencia. CRACI no firma la procedencia. Sigue reevaluando las SBOM monitorizadas.

CRACI no hace lo que distingue a Kusari: no ingiere resultados de otros escáneres, no analiza la alcanzabilidad ni revisa pull requests en busca de paquetes maliciosos y debilidades del código. Solo es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta.

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.

Sustituir Kusari por CRACI

Para el software que usted compila y distribuye, CRACI cubre aquello para lo que suele comprarse una plataforma de grafos. Ejecuta el build, registra la SBOM con su completitud indicada, 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. La política de egress limita de entrada a qué puede acceder un build, algo que ningún grafo puede hacer.

Tenga claro a qué renuncia. Kusari conecta en un solo grafo muchos escáneres y fuentes de SBOM, ingiere VEX, analiza la alcanzabilidad y revisa pull requests en busca de paquetes maliciosos, secretos filtrados y debilidades del código. CRACI no hace nada de eso hoy, y solo es compatible con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta. Si su principal necesidad es correlacionar hallazgos de muchas herramientas existentes, Kusari sigue siendo la opción más adecuada.

Para el CRA

El Cyber Resilience Act pide a los fabricantes que documenten los componentes de sus productos, incluida una SBOM, y que gestionen las vulnerabilidades mientras el producto tenga soporte. La notificación de vulnerabilidades explotadas activamente se aplica desde septiembre de 2026. Kusari conecta SBOM, VEX y hallazgos en un solo grafo, e incluye el CRA entre los marcos compatibles. CRACI genera la evidencia por build y la sigue monitorizando: a partir de qué se compiló cada versión, con procedencia, monitorización continua y exportación de SBOM en CycloneDX o SPDX. 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; ninguna de las dos herramientas hace que un producto cumpla por sí sola. Lea qué exige el CRA.

Migrar a CRACI

Defina runs-on: craci en los workflows que compilan lo que usted distribuye. CRACI sustituye el runner, no GitHub Actions, y las ejecuciones siguen apareciendo en la interfaz de GitHub. Más información sobre la generación de SBOM durante el build y el seguimiento de vulnerabilidades.

¿Valora más de dos herramientas? Alternativas a Kusari compara nueve opciones una junto a otra.