CRACI frente a Harness

La respuesta corta

Harness, fundada en 2017 y con sede en San Francisco, vende una plataforma para todo lo que viene después de escribir el código: integración continua, entrega continua, feature flags, gestión de costes de nube, chaos engineering y pruebas de seguridad. Su módulo Supply Chain Security (SCS) añade generación de SBOM, procedencia SLSA, controles de política OPA y comprobaciones de postura para repositorios y pipelines. Si quiere un único proveedor para todo el pipeline de entrega, con varios proveedores de Git, Harness está pensado para eso.

CRACI es más específico y profundiza más en el build. Es un runner de GitHub Actions: mientras se ejecuta cada job, registra cada dependencia externa que incorpora el build, aplica una política de egress en la red del build y genera SBOM, datos de procedencia y monitorización de vulnerabilidades a partir de ese registro. Harness añade pasos de cadena de suministro a un pipeline; CRACI convierte el propio runner en el registro de seguridad.

Antes de nada, un punto práctico. CRACI solo es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta. Los pipelines de Harness CI tendrían que migrar a GitHub Actions para ejecutarse en CRACI.

De un vistazo

Lo que Harness hace bien

Una plataforma para la entrega. Harness cubre CI, CD, GitOps, feature flags, infraestructura como código, chaos engineering y gestión de costes de nube, con aplicación de políticas basada en OPA en todo ello. Funciona con GitHub, GitLab, Bitbucket, Azure Repos y sus propios repositorios Harness Code, y afirma atender a más de 1.000 clientes empresariales con más de 1.200 empleados.

Elección de infraestructura de build. Harness Cloud ejecuta builds en máquinas Linux, Windows y macOS gestionadas por Harness: Linux AMD64 de 2 a 96 núcleos, ARM64 de 2 a 64 núcleos a la misma tarifa y macOS en Apple M4. La virtualización anidada está disponible en Linux AMD64. También puede ejecutar builds en sus propios clústeres de Kubernetes, máquinas virtuales o bare metal. Test Intelligence ejecuta solo las pruebas a las que afecta un cambio, y Build Intelligence y las funciones de caché reutilizan salidas y dependencias sin cambios.

Funciones de cadena de suministro en el pipeline. El paso SBOM Orchestration del módulo SCS genera una SBOM para una imagen de contenedor o un repositorio de código con Syft o cdxgen, en SPDX o CycloneDX, y puede ingerir SBOM de otras herramientas. Harness afirma que genera y actualiza SBOM en cada build. Las políticas OPA pueden bloquear builds y despliegues por componentes, licencias o procedencia, y un registro de correcciones hace el seguimiento de los artefactos vulnerables.

Procedencia SLSA. Harness documenta SLSA Build Level 1, 2 y 3 bajo SLSA v1.0, con procedencia firmada mediante atestaciones in-toto y cosign. Su documentación indica que el Level 3 necesita infraestructura de build reforzada o Harness Cloud, que aísla los procesos de build entre sí.

Comprobaciones de postura y de pipelines. SCS audita repositorios y pipelines frente al OWASP Top 10 CI/CD Security Risks y los CIS benchmarks, y señala las GitHub Actions sin fijar, sin verificar y con permisos excesivos. Harness también ofrece sus pasos de SCS como GitHub Actions y componentes de GitLab CI/CD, de modo que el módulo no está ligado a Harness CI; esos pasos necesitan una cuenta de Harness con licencia de SCS.

En qué se diferencia CRACI

La SBOM sale del build, no de un escaneo de su salida

Syft y cdxgen son escáneres: leen una imagen o un repositorio a posteriori e infieren lo que contiene a partir de lockfiles, manifiestos y bases de datos de paquetes. Eso funciona bien cuando esos archivos lo cuentan todo. Los builds suelen hacer más: los scripts de instalación descargan código, los scripts de build de Rust descargan durante el build y las cachés restauran paquetes que ningún lockfile menciona.

CRACI ve ese tráfico porque es el runner. Un proxy que entiende de paquetes registra lo que cada job descarga de las fuentes de paquetes, en fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga, y la evidencia de dependencias viaja con las cachés de CI. Registra las dependencias ocultas que pasan por alto las herramientas basadas en lockfiles, y cada SBOM indica su grado de completitud, por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

Una política en la red del build, no detección a posteriori

Harness afirma que su módulo detecta comportamientos anómalos de los runners de CI, incluidas las llamadas de red y la escalada de privilegios. CRACI toma el otro camino: una política de egress en el runner decide a qué hosts puede acceder un job. Las políticas son de denegación por defecto o de permiso por defecto, con 24 presets de fuentes de software integrados y fuentes personalizadas tipadas, se validan antes de que empiece el job y, si fallan, bloquean. Como una política de denegación por defecto solo permite lo que el build necesita en lugar de buscar hosts maliciosos conocidos, bloquea la exfiltración al servidor de un atacante incluso en un ataque que nadie haya visto antes. Las infracciones envían una alerta.

Procedencia y monitorización a partir del mismo registro

La API devuelve SBOM, trazas de red y procedencia. CRACI no firma la procedencia y no reivindica ningún nivel SLSA; Harness firma su procedencia y documenta los niveles 1 a 3, y si la procedencia firmada o un nivel SLSA es un requisito de compra, eso cuenta a favor de Harness. CRACI agrega las vulnerabilidades de todos los builds y repositorios, sigue reevaluando las SBOM monitorizadas a medida que aparecen avisos y muestra qué builds anteriores contenían una dependencia vulnerable, para que sepa durante qué periodo estuvo afectado.

Precios que se pueden leer

CRACI solo cobra por los minutos de build: $0.002 por vCPU-minuto ($0.004 con un runner de 2 vCPU por defecto), facturados por segundo, sin cuota mensual ni cargo por SBOM. Harness publica sus tarifas de Harness Cloud, $0.005 por minuto para una máquina Linux de 2 núcleos con 7 GB y $0.080 para 32 núcleos, facturadas al minuto más cercano, mientras que sus planes de pago y el módulo SCS se contratan a través de ventas. El precio de lista de CRACI es un 20 % menor por minuto en ambos tamaños ($0.004 frente a $0.005, $0.064 frente a $0.080); las máquinas de Harness tienen más memoria por núcleo.

Cuál le conviene

• Siga con Harness si quiere CI, CD, feature flags y gestión de costes de un solo proveedor, si su código está en GitLab, Bitbucket o Azure Repos, si necesita Windows, macOS o su propio hardware de build, o si un SLSA Build Level 3 documentado es un requisito.
• Elija CRACI si su código está en GitHub y utiliza o tiene previsto utilizar GitHub Actions, y quiere que la SBOM, la política de red y la procedencia salgan del runner que hizo el build, con un precio por minuto de build.

Tenga claro a qué renuncia al elegir CRACI. No despliega software, no ejecuta feature flags ni gestiona costes de nube, y no comprueba repositorios ni pipelines frente a benchmarks de postura ni escanea código fuente. Hoy solo ejecuta jobs de Linux, con Windows y macOS en la hoja de ruta, y los runners alojados por el cliente están en la hoja de ruta para Enterprise.

Para productos regulados

Marcos como el Cyber Resilience Act de la UE esperan que los fabricantes sepan qué contiene cada versión y gestionen sus vulnerabilidades, con obligaciones de notificación desde septiembre de 2026. Harness aporta SBOM, procedencia y resultados de políticas desde sus pasos de pipeline. CRACI genera la evidencia a partir del registro del build 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 una empresa necesita para su proceso más amplio del CRA; ninguna de las dos herramientas hace que un producto cumpla por sí sola.

Migrar un pipeline a CRACI

CRACI sustituye el runner, no GitHub Actions, y las ejecuciones siguen apareciendo en la interfaz de GitHub. Cuando un pipeline ya funciona como workflow de GitHub Actions, se ejecuta en CRACI con una línea:

runs-on: craci

Más información sobre la generación de SBOM durante el build, compare plataformas de CI/CD, consulte las alternativas a Harness o vea los precios.