CRACI frente a Syft y Grype

La respuesta corta

Syft es un popular generador de SBOM de código abierto, y Grype es su escáner de vulnerabilidades complementario. Juntos cubren la generación y el cotejo de forma gratuita, en cualquier pipeline. CRACI es un runner de GitHub Actions que registra lo que descargó cada build, indica si ese registro está completo, controla a dónde puede conectarse el build y sigue monitorizando lo distribuido. La diferencia en una línea: Syft reconstruye la SBOM a partir de archivos, y lo que encuentra depende de su configuración y de lo que haya en disco cuando se ejecuta. CRACI la observa, y hace el seguimiento de las vulnerabilidades de lo que registró, de modo que un solo producto hace el trabajo de ambos.

Lo que Syft y Grype hacen bien

Syft es «a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems». Reconoce decenas de sistemas de empaquetado, desde Alpine, Debian y RPM hasta Go, Python, Java, JavaScript, Ruby, Rust, PHP y .NET. Escribe CycloneDX, SPDX y su propio Syft JSON, convierte entre formatos y puede crear atestaciones de SBOM firmadas con la especificación in-toto.

Grype escanea imágenes de contenedor, sistemas de archivos y SBOM en busca de vulnerabilidades conocidas. Prioriza los hallazgos con EPSS, KEV y puntuación de riesgo, admite OpenVEX para filtrar resultados, y su flag --fail-on hace fallar un pipeline cuando encuentra vulnerabilidades de la gravedad que usted elija o superior. Anchore señala que Grype «runs entirely locally and doesn't send any data to external services», salvo por la descarga de su base de datos.

Ambos son Apache-2.0 y están patrocinados por Anchore, cuya plataforma comercial, Anchore Enterprise, «builds on open source Syft and Grype». Esta página trata de las herramientas de código abierto.

Syft destaca cuando tiene delante los archivos adecuados. Si se le indica un árbol de código fuente que incluye sus dependencias, como ollama/ollama, su escaneo por defecto las resuelve con versiones, package URLs y las relaciones de dependencia entre ellas.

Un flag cambia la respuesta

Syft elige sus catalogers según el tipo de escaneo, y su documentación explica por qué: «files that hint at the intent to install software do not have enough information in them to determine the exact version». Los catalogers llevan etiquetas como declared, installed, image y directory, y flags como --select-catalogers y --override-default-catalogers cambian el conjunto.

En syft cataloger list, en la v1.51.1, el cataloger de JavaScript que lee node_modules está etiquetado para escaneos de imágenes e instalaciones y no forma parte del conjunto por defecto para un escaneo de directorio. Así, en un checkout con las dependencias instaladas, un solo flag decide si los paquetes npm de node_modules se leen o no. La misma herramienta, la misma versión, el mismo árbol.

La otra cara importa igual. Ninguna configuración es correcta en todos los casos:

• En un checkout limpio de express 5.2.1, que no tiene lockfile, el escaneo por defecto no tiene dependencias npm que resolver y devuelve cualquier otra cosa que reconozca, como GitHub Actions y archivos de workflow.
• Active los catalogers de instalación e indíqueles árboles de código fuente tal como están en el repositorio, donde todavía no se ha instalado nada, y casi no tendrán nada que leer.
• Un repositorio sin ningún manifiesto de dependencias no da al escaneo ningún archivo de dependencias que leer, sea cual sea la configuración.

Nada de esto es un error. Syft informa de lo que permiten los archivos que tiene delante, tal como está diseñado. La consecuencia práctica es que la SBOM depende de dos decisiones que alguien tiene que acertar en cada pipeline: qué catalogers se ejecutan y si las dependencias se instalaron antes del escaneo. Y Grype solo puede cotejar lo que Syft enumeró. Un componente que falta en la SBOM nunca llega a la búsqueda de vulnerabilidades, así que el escaneo sale limpio para él.

En qué se diferencia CRACI

CRACI no tiene catalogers que elegir, porque no lee el árbol a posteriori. Usted cambia runs-on a craci, y un proxy que entiende de paquetes registra lo que el job descarga de fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de presets de descarga. Los paquetes restaurados desde una caché de CI conservan su evidencia. El resultado, en CycloneDX o SPDX, incluye las dependencias transitivas que el build utilizó realmente.

• La completitud es explícita. Cada job y caché se marca como Complete, Complete with connections, Incomplete, Unavailable o Not recorded.
• El build está controlado. Una política de egress (denegación o permiso por defecto, 24 presets de fuentes de software integrados) se valida antes de que empiece el job y bloquea si falla (fail closed).
• Datos de procedencia. La API devuelve SBOM, trazas de red y datos de procedencia. CRACI no firma la procedencia; una atestación de Syft firma la SBOM.
• Monitorización. Las SBOM monitorizadas se reevalúan continuamente, y los hallazgos se agregan de todos los builds y repositorios.

Grype sigue haciendo cosas que CRACI no hace. El filtrado VEX y el escaneo de imágenes que usted no generó son terreno de Grype. Los controles de política de CRACI pueden hacer fallar el build; sus alertas por umbral están 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.

Migrar desde Syft y Grype

En CRACI no hay ninguna SBOM que generar ni ningún paso de escaneo que mantener. El runner registra la SBOM mientras se ejecuta el build, y CRACI sigue comprobándola en busca de nuevas vulnerabilidades una vez terminado el build. Syft y Grype siguen siendo las herramientas para imágenes y software de terceros que usted no generó, y para pipelines fuera de GitHub Actions.

Para el Cyber Resilience Act

El CRA pide a los fabricantes que documenten los componentes de cada producto, incluida una SBOM, y que gestionen sus vulnerabilidades. Syft y Grype pueden producir y comprobar esa SBOM, y construir el rastro de evidencia de cada versión hasta su SBOM queda en manos de usted. CRACI registra la SBOM por build y la exporta en CycloneDX o SPDX. 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. Consulte qué es el CRA y la generación de SBOM durante el build.