CRACI frente a Mend.io

La respuesta corta

Mend.io es una plataforma de seguridad de aplicaciones. Mend AppSec combina Mend SAST para su propio código con Mend SCA para dependencias de código abierto y contenedores, y Mend Renovate mantiene al día las dependencias con pull requests automatizadas. CRACI es un runner de CI compatible con GitHub Actions que registra cada dependencia externa que descarga un build y genera la SBOM, la procedencia y la evidencia de cumplimiento a partir de ese registro. Mend es un escáner. CRACI es un registrador. Si hoy utiliza Mend, CRACI añade una capa en lugar de sustituir una.

De un vistazo

Lo que Mend.io hace bien

Priorizar lo que es alcanzable. Mend SCA sigue el grafo de llamadas desde su código a través de las dependencias directas y transitivas para decidir si su aplicación invoca realmente una función vulnerable. Eso reduce la lista de hallazgos sobre los que un equipo tiene que actuar. CRACI agrega las vulnerabilidades de todos los builds y repositorios, pero no realiza análisis de alcanzabilidad.

El código además de las dependencias. Mend SAST cubre más de 30 lenguajes, y Mend CLI escanea componentes de código abierto, código propio, imágenes de contenedor e infraestructura como código. CRACI no hace nada de esto.

Mantener al día las dependencias. Mend Renovate abre pull requests para los paquetes desactualizados en más de 90 gestores de paquetes. Las ediciones Renovate CLI y Community son gratuitas; Enterprise añade funciones de seguridad y soporte.

Licencias, paquetes maliciosos y SBOM. Mend SCA detecta las licencias de las dependencias directas y transitivas y aplica políticas, como bloquear AGPL en productos comerciales. Señala typosquats, confusión de dependencias y paquetes con puertas traseras o código de exfiltración de datos. Produce SBOM en SPDX y CycloneDX, ingiere SBOM de terceros y aplica datos VEX.

En qué se diferencia CRACI

Observación en lugar de reconstrucción

La propia documentación de Mend recomienda escanear después del paso de build, porque el build es lo que da al escáner acceso a registros privados y artefactos externos, y escanear sin compilar puede dar resultados inexactos. Es una buena intuición. CRACI va un paso más allá: en lugar de leer el proyecto cuando el build ha terminado, registra el propio build.

Un proxy en el runner de CRACI que entiende de paquetes observa el tráfico hacia las fuentes de paquetes mientras se ejecuta el job, para fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga. La evidencia de dependencias viaja con las cachés de CI, así que los paquetes restaurados desde una caché siguen contando. Cada SBOM indica su completitud por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

Control sobre la red del build

Como CRACI ejecuta el job, puede limitar a dónde va. Las políticas de egress son de denegación por defecto o de permiso por defecto, con 24 presets integrados de fuentes de software y fuentes personalizadas tipadas para npm, PyPI, apt, apk, el proxy de Go, Nix, Cargo, registros OCI y Git. Se validan antes de que empiece el job y, si fallan, bloquean. Mend detecta un paquete malicioso una vez que está en su árbol de dependencias. Una política de egress limita de entrada a qué fuentes puede acceder un build. Las dos capas actúan en momentos distintos.

Evidencia del build

La API devuelve SBOM, trazas de red y procedencia. CRACI no firma la procedencia.

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.

Cuál le conviene

• Su principal problema es un backlog de hallazgos en código y dependencias. Mend, con SAST, alcanzabilidad y Renovate, está pensado para eso.
• Necesita demostrar qué entró en cada versión. CRACI lo registra por build e indica cuán completo es el registro.
• Sus builds hacen más que instalar desde un lockfile. Las descargas de toolchains, las imágenes base y las descargas con curl son donde más aporta la observación.
• Sus pipelines están en Azure DevOps, Bitbucket o CircleCI. Mend ya funciona con ellos. CRACI solo es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta.

Para el Cyber Resilience Act

Mend.io publica una guía de cumplimiento del CRA y una página de cumplimiento que relaciona sus productos con el reglamento: Mend AppSec para las SBOM en CycloneDX y SPDX y la priorización basada en la alcanzabilidad, Mend Renovate para la gestión continua de vulnerabilidades mediante actualizaciones de dependencias, y el cumplimiento de licencias documentado junto a la postura de seguridad.

CRACI aporta evidencia del build: una SBOM de cada versión con su completitud indicada, procedencia, monitorización continua y exportación de SBOM 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. Ninguna herramienta por sí sola hace que un producto cumpla. Consulte el cumplimiento del CRA y qué es el CRA.

Añadir CRACI junto a Mend.io

CRACI sustituye el runner, no GitHub Actions. Cambie runs-on a craci en un workflow y las ejecuciones seguirán apareciendo en la interfaz de GitHub. Su paso de Mend CLI se queda donde está, después del build. Ejecute un pipeline de lanzamiento en CRACI y compare su SBOM con el inventario de Mend para el mismo commit.