Comparativa
CRACI frente a GitLab CI
GitLab escanea su proyecto e informa de lo que declaran sus lockfiles. CRACI es el runner, así que registra lo que cada build descargó realmente. La diferencia está en de dónde salen su SBOM y su procedencia.
Actualizado el
La respuesta corta
GitLab es una plataforma DevSecOps completa: control de código fuente, merge requests, planificación y CI/CD en un solo producto, con un amplio conjunto de escáneres de seguridad y gestión de vulnerabilidades en su nivel Ultimate. Si quiere un único proveedor para todo el ciclo de vida del software, GitLab está pensado para eso.
CRACI es más específico. Es un runner compatible con GitHub Actions que registra cada dependencia externa que descarga un build, controla a qué puede acceder el build y convierte ese registro en SBOM, datos de procedencia y evidencia para el CRA. La diferencia de fondo es un CI tradicional con escáneres añadidos frente a un CI en el que el propio runner es el registro de seguridad.
Antes de nada, un punto práctico. CRACI solo es compatible hoy con GitHub Actions; GitLab CI y Jenkins están en la hoja de ruta. Si sus pipelines están en GitLab CI, tendría que migrarlos a GitHub Actions para usar runners de CRACI, o esperar a la compatibilidad con GitLab CI, que está en la hoja de ruta.
| Función | CRACI | GitLab |
|---|---|---|
| Dependencias registradas desde el build | Descargas observadas, incluidos los paquetes de cachés de CI | Los escáneres leen lockfiles y exportaciones del grafo de dependencias |
| Exportación de SBOM | CycloneDX o SPDX por build, con estado de completitud | Informes CycloneDX; exportación de la lista de dependencias en Ultimate |
| Política de egress de la red del build | Denegación o permiso por defecto; si falla, bloquea | Sus propios controles de red en runners autogestionados |
| Procedencia del build | Datos de procedencia mediante la API; sin firmar | Declaración de procedencia SLSA 1.0 desde el runner |
| Monitorización continua de vulnerabilidades | Las SBOM monitorizadas se reevalúan de forma continua | Escaneo continuo de vulnerabilidades en Ultimate |
| Informes de cumplimiento | SBOM en CycloneDX o SPDX, registros mediante API; sin exportación de informes | Funciones de cumplimiento y gobernanza en Ultimate |
| SAST, detección de secretos, DAST | SAST básico y secretos en todos los niveles; DAST en Ultimate | |
| Control de código fuente y planificación | Funciona con sus repositorios de GitHub | Repositorios, merge requests y planificación en una sola plataforma |
| Sistemas de CI compatibles | GitHub Actions hoy; GitLab CI y Jenkins en la hoja de ruta | GitLab CI/CD, alojado o autogestionado |
| Plataformas de runners alojados | Linux en x86-64 y ARM64, de 1 a 32 vCPU. Windows y macOS en la hoja de ruta. | Linux en x86-64 y arm64; runners alojados de Windows y macOS en beta. |
| Precios | Pago por minuto de build: $0.004 por minuto con 2 vCPU, facturado por segundo. Sin cuota mensual ni cargo por SBOM. | Free con 400 minutos de cómputo; Premium $29 por usuario al mes con facturación anual; Ultimate con precio personalizado (a septiembre de 2026). |
- Incluido
- En parte
- No incluido
- En la hoja de ruta
Lo que GitLab hace bien
Una sola plataforma. El código, las revisiones, los pipelines, los hallazgos de seguridad y la planificación están en el mismo lugar, con un único modelo de permisos. Para muchas organizaciones, eso por sí solo decide la cuestión.
Escaneo de seguridad, por nivel. Conviene precisar qué incluye cada nivel. Según GitLab, el SAST básico, la detección de secretos y el escaneo de contenedores funcionan en todos los niveles, incluido Free. En Free y Premium, esos escaneos producen artefactos de informe en JSON. Ultimate añade el workflow que los rodea: hallazgos en las merge requests, el informe de vulnerabilidades, la lista de dependencias, las aprobaciones de seguridad y GitLab Advanced SAST. El escaneo de dependencias, el escaneo continuo de vulnerabilidades y el DAST son funciones de Ultimate. El escaneo de contenedores también puede producir un informe de SBOM en CycloneDX en todos los niveles.
Procedencia. GitLab Runner puede generar una declaración de procedencia de artefactos en formato SLSA 1.0 en todos los niveles. También existen atestaciones SLSA Level 3 firmadas, pero GitLab las indica como un experimento en GitLab.com para Ultimate, tras un feature flag desactivado por defecto.
Elección de runners. Los runners alojados por GitLab cubren Linux en x86-64 (de 2 a 32 vCPU) y arm64, con Windows y macOS en beta. También puede ejecutar sus propios runners en cualquier sitio, y GitLab indica que los jobs en sus propios runners no consumen minutos de cómputo. GitLab Dedicated añade residencia de datos en la región que usted elija.
En qué se diferencia CRACI
La SBOM sale del build, no del lockfile
El escaneo de dependencias basado en SBOM de GitLab detecta dependencias a partir de lockfiles compatibles o de exportaciones del grafo de dependencias. Es un enfoque sólido cuando el lockfile lo cuenta todo. Los builds suelen hacer más: ejecutan scripts de instalación, descargan toolchains, restauran cachés y descargan imágenes base.
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, en 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 un paquete restaurado desde una caché sigue contando. Cada job genera una SBOM en CycloneDX o SPDX.
La completitud se indica, no se supone
Cada SBOM lleva un estado de completitud por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Cuando el registro tiene una laguna, puede verla.
La red del build es una política
Las políticas de egress de CRACI son de denegación por defecto o de 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, bloquean si fallan y envían una alerta ante una infracción. En GitLab, el control de red de los builds es lo que usted configure en torno a sus propios runners.
Procedencia
La API devuelve SBOM, trazas de red y procedencia. CRACI no firma la procedencia y no reivindica ningún nivel SLSA.
Monitorizar lo distribuido
CRACI agrega las vulnerabilidades de todos los builds y repositorios y sigue reevaluando las SBOM monitorizadas a medida que aparecen nuevos avisos.
Cuál le conviene
- Siga con GitLab si su código y sus pipelines están en GitLab y quiere una sola plataforma, o si necesita SAST, DAST y detección de secretos en el mismo producto.
- Elija CRACI si su código está en GitHub y utiliza GitHub Actions, y necesita evidencia de lo que entró en cada versión, control sobre a qué pueden acceder los builds y SBOM que pueda defender en una auditoría.
- Use los dos si su organización utiliza ambas plataformas. GitLab sigue cubriendo sus proyectos y escáneres; CRACI ejecuta la parte de GitHub Actions y registra esos builds.
Para el Cyber Resilience Act
Según el Cyber Resilience Act de la UE, los fabricantes deben saber qué hay en cada versión de un producto y gestionar sus vulnerabilidades. Las obligaciones de notificación de vulnerabilidades se aplican desde septiembre de 2026, y el reglamento se aplica en su totalidad desde diciembre de 2027. GitLab Ultimate ayuda a encontrar y gestionar vulnerabilidades en sus proyectos. CRACI registra a partir de qué se compiló cada versión, sigue monitorizándola y exporta las 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 de las dos herramientas basta por sí sola para cumplir.
Añadir CRACI
Para un repositorio en GitHub, instale la GitHub App de CRACI en su organización, para todos los repositorios o para un conjunto seleccionado, y cambie la etiqueta del runner:
runs-on: craciLos workflows, las acciones y la interfaz de GitHub siguen igual. CRACI sustituye el runner, no GitHub Actions. Más información sobre la generación de SBOM durante el build y la evidencia para el CRA, o consulte los precios.
Vea lo que incorpora realmente un build
Ejecute un workflow de GitHub Actions en CRACI y compare su SBOM con la que generan hoy sus escáneres.
Reservar una demo