CRACI frente a Snyk

Dos preguntas distintas

Si ya utiliza Snyk, tiene una buena respuesta a una pregunta: ¿cuáles de los paquetes de código abierto que declara mi proyecto tienen vulnerabilidades conocidas o problemas de licencia, y cómo los corrijo? Snyk es en esencia una herramienta de análisis de composición de software (SCA), y hace bien ese trabajo. También cubre el código propio, las imágenes de contenedor y la infraestructura como código.

CRACI responde a otra pregunta: ¿qué descargó realmente este build y de dónde? CRACI es un runner de CI. Sus jobs de GitHub Actions se ejecutan en él y, mientras lo hacen, registra cada dependencia externa que descargan. La SBOM, la procedencia y la evidencia de cumplimiento salen todas de ese registro.

Las dos herramientas se sitúan en puntos distintos del pipeline, por lo que esto es menos un enfrentamiento directo y más un mapa de quién cubre qué.

Lo que Snyk hace bien

Snyk está pensado para desarrolladores. Funciona en el IDE, en la CLI, sobre sus repositorios mediante integraciones con SCM, y en el CI. Para las dependencias de código abierto, prioriza los hallazgos con factores como la alcanzabilidad, la madurez del exploit y las puntuaciones EPSS y CVSS, y puede abrir pull requests que aplican la actualización por usted. Monitoriza los proyectos en busca de vulnerabilidades recién divulgadas y admite políticas de licencias.

Más allá de las dependencias, Snyk Code (SAST), Snyk Container y Snyk Infrastructure as Code cubren un terreno que CRACI no toca en absoluto. CRACI no es una herramienta de análisis estático y no escanea su Terraform. Si necesita eso, Snyk o una herramienta similar sigue en su stack.

Snyk también empieza antes, a partir de las dependencias que declara su proyecto, y acompaña sus correcciones de pull requests de actualización, priorización, información en el IDE y políticas de licencias. Si quiere orientar a los desarrolladores hacia las actualizaciones desde el editor en adelante, ese es claramente el terreno de Snyk.

En qué se diferencia CRACI

Registra el build en lugar de leer el manifiesto

Snyk construye su árbol de dependencias a partir del manifiesto y los lockfiles de su proyecto. Eso funciona bien cuando el manifiesto cuenta toda la historia. Los builds a menudo hacen más: ejecutan scripts de instalación, descargan toolchains, restauran cachés, descargan imágenes base y obtienen binarios de versiones con curl.

CRACI ve esa actividad porque es el runner. Un proxy que entiende de paquetes observa el tráfico hacia las fuentes de paquetes mientras se ejecuta el job. Los ecosistemas detectados incluyen fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de presets de descarga. La evidencia de dependencias viaja con las cachés de CI, de modo que un paquete restaurado desde una caché también se tiene en cuenta.

CRACI también le dice cómo de completa es cada SBOM. La completitud se indica por job y por caché, en cinco estados: Complete, Complete with connections, Incomplete, Unavailable y Not recorded. Usted sabe cuándo el registro tiene una laguna, en lugar de suponer que no la tiene.

Controla la red del build

Como el build se ejecuta en CRACI, usted puede fijarle una política de egress. Las políticas son de denegación o permiso por defecto, con 24 presets de fuentes de software integrados y fuentes personalizadas tipadas para npm, PyPI, apt, apk, el proxy de Go, Nix, Cargo, registros OCI y Git. Las políticas se validan antes de que empiece el job y bloquean si fallan (fail closed). CRACI puede avisarle cuando un job infringe su política.

Un escáner revisa lo que declara un proyecto. Un control en tiempo de ejecución limita a qué puede acceder el build mientras se ejecuta. Son capas complementarias.

Registra el propio build

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

Produce evidencia de cumplimiento a partir del mismo registro

Para normativas como el Cyber Resilience Act de la UE, usted debe demostrar qué contiene cada versión y cómo hace el seguimiento de sus vulnerabilidades. CRACI agrega las vulnerabilidades de todos los builds y repositorios, sigue reevaluando las SBOM monitorizadas y las 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. Lea más sobre la evidencia para el CRA y el cumplimiento del CRA.

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.

Una nota sobre el acceso a las SBOM

Snyk puede exportar SBOM en CycloneDX y SPDX con el comando snyk sbom. Según la documentación de Snyk, ese comando solo está disponible para clientes de los planes Snyk Enterprise. Con CRACI, cada build en el runner produce una SBOM sin coste adicional: CRACI solo factura minutos de build. Consulte los precios para conocer las condiciones vigentes.

Cuándo usar ambos

Una configuración habitual es esta:

• Snyk en el IDE y en las pull requests, para detectar dependencias vulnerables, problemas de código y errores de configuración de IaC antes de la fusión, y para abrir pull requests de corrección.
• CRACI como runner de sus workflows de GitHub Actions, para registrar lo que descargó cada build, aplicar la política de egress, producir la SBOM y los datos de procedencia de cada build y conservar la evidencia para las auditorías.

Las GitHub Actions de Snyk pueden ejecutarse en runners de CRACI como cualquier otro paso. CRACI sustituye el runner, no GitHub Actions, y las ejecuciones siguen apareciendo en la interfaz de GitHub.

Snyk por sí solo encaja mejor si no distribuye software en un mercado regulado, sus builds son simples y se rigen por manifiestos, y su prioridad es corregir rápidamente los problemas conocidos. Plantéese añadir CRACI cuando necesite evidencia de qué entró en cada versión, control sobre a qué pueden acceder los builds o SBOM que pueda defender en una auditoría.

CRACI y Snyk: preguntas frecuentes

Precios, exportación de SBOM y dónde encaja cada herramienta

¿Es CRACI una alternativa a Snyk?

Para una parte de lo que hace Snyk. CRACI registra la SBOM de cada build de GitHub Actions, sigue reevaluando las SBOM monitorizadas en busca de nuevas vulnerabilidades y permite a los equipos de seguridad hacer el triaje de los hallazgos y enviarlos al equipo responsable de la corrección. No ofrece SAST, escaneo de contenedores ni de IaC, ni análisis de alcanzabilidad, así que es una alternativa cuando su pregunta es a partir de qué se generó cada versión, no un sustituto del escaneo de código de Snyk.

¿CRACI sustituye a Snyk o funciona junto a él?

La mayoría de los equipos los ejecutan en paralelo. Snyk funciona en el IDE y en las pull requests, y detecta dependencias vulnerables, problemas de código y errores de configuración de IaC antes de la fusión. CRACI es el runner de sus workflows de GitHub Actions: registra lo que descargó cada build, aplica la política de egress y produce la SBOM y los datos de procedencia. Las GitHub Actions de Snyk se ejecutan en runners de CRACI como cualquier otro paso.

¿Cómo se comparan los precios de CRACI con los de Snyk?

Cobran por cosas distintas. A septiembre de 2026, Snyk tiene un plan Free, Team desde $25 al mes y un plan Enterprise. CRACI cobra solo por los minutos de build, $0.002 por vCPU-minuto ($0.004 para un runner de 2 vCPU por defecto), sin cuota mensual ni cargo por SBOM; consulte los precios para conocer las condiciones vigentes.

¿Qué plan de Snyk incluye la exportación de SBOM?

Según la documentación de Snyk, el comando snyk sbom, que exporta CycloneDX y SPDX, solo está disponible en los planes Snyk Enterprise. Con CRACI, cada build en el runner produce una SBOM, exportada en CycloneDX o SPDX con dependencias transitivas y un estado de completitud por job y por caché.

¿Qué hace Snyk que CRACI no haga?

Snyk Code (SAST), Snyk Container y Snyk Infrastructure as Code cubren un terreno que CRACI no toca. Snyk también prioriza los hallazgos de código abierto por alcanzabilidad, madurez del exploit, EPSS y CVSS, abre pull requests de actualización y da a los desarrolladores información en el IDE. CRACI no ofrece análisis de alcanzabilidad.

¿Con qué sistemas de CI son compatibles Snyk y CRACI?

Snyk funciona en el IDE, en la CLI, mediante integraciones con SCM y en pipelines de CI. CRACI es hoy un runner para GitHub Actions; otros sistemas de CI están en la hoja de ruta, entre ellos GitLab CI y Jenkins. CRACI sustituye el runner, no GitHub Actions, así que las ejecuciones siguen apareciendo en GitHub.

¿Ayuda CRACI con el Cyber Resilience Act?

Sí. CRACI registra qué contiene cada versión, sigue monitorizando sus vulnerabilidades, exporta las SBOM en CycloneDX o SPDX y envía en su nombre las notificaciones de vulnerabilidades del CRA. Automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro que necesita su proceso del CRA; cumplir el CRA sigue siendo un proceso del fabricante. Reserve una demo para ver la evidencia de uno de sus propios builds.