CRACI frente a CircleCI

La respuesta corta

CircleCI es una plataforma de CI/CD madura y flexible. Se conecta a GitHub, GitLab y Bitbucket, ejecuta jobs en una amplia variedad de máquinas, desde contenedores Docker hasta macOS y GPU, y permite empaquetar configuración reutilizable en orbs. En cuanto a la seguridad, CircleCI protege las credenciales y deja el escaneo a los orbs y a herramientas de terceros.

CRACI adopta el enfoque contrario: el runner es el registro de seguridad. Ejecuta jobs de GitHub Actions, observa cada dependencia externa que descarga cada build, aplica una política de egress en la red del build y genera SBOM, datos de procedencia y evidencia para el CRA a partir de lo que vio. Esa es la diferencia entre un CI tradicional y un CI pensado para la seguridad.

CRACI solo es compatible hoy con GitHub Actions, con GitLab CI y Jenkins en la hoja de ruta. CircleCI todavía no es compatible. Los equipos que usan CircleCI tendrían que migrar un pipeline a GitHub Actions para usar los runners de CRACI, o esperar a otros sistemas de CI, que están en la hoja de ruta.

Lo que CircleCI hace bien

Variedad de cómputo. CircleCI ofrece clases de recursos Docker, Linux VM, Arm, Windows, macOS y GPU, así que una sola plataforma puede compilar un backend, un cliente de Windows y una app de iOS. Los runners autoalojados amplían eso a sus propias máquinas Linux, Windows y macOS y a Kubernetes, y el tiempo de los jobs en esos runners no consume créditos.

Funciones de velocidad. La caché de capas de Docker está disponible en todos los planes. La división de pruebas reparte una suite entre ejecutores paralelos por nombre, tamaño de archivo o datos históricos de tiempos, lo que reduce el tiempo real en las suites de pruebas grandes.

Configuración reutilizable. Los orbs empaquetan jobs, comandos y ejecutores para que los equipos los reutilicen entre proyectos, y facilitan conectar herramientas de terceros, incluidos los escáneres de seguridad.

Higiene de credenciales. Las recomendaciones de CircleCI sobre la cadena de suministro se centran en proteger los secretos: repartirlos en contexts, poner las claves de despliegue y de firma en contexts restringidos que gobiernan sus grupos del VCS, y usar tokens OIDC para que los jobs accedan a servicios en la nube sin credenciales de larga duración almacenadas en CircleCI.

En qué se diferencia CRACI

El build es la fuente de verdad

En una plataforma de CI tradicional, la SBOM la genera una herramienta que usted añade al pipeline y que normalmente lee manifiestos y lockfiles. CRACI, en cambio, observa el build. Un proxy que entiende de paquetes registra 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.

Usted sabe cuán completa es la SBOM

Cada job genera una SBOM CycloneDX o SPDX con un estado de completitud por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

La red del build tiene una política

La función de rangos de IP de CircleCI enruta los jobs a través de direcciones conocidas de CircleCI para que sus propios sistemas puedan incluirlas en una lista de permitidos. Eso resuelve el acceso entrante. CRACI añade control en la dirección contraria: políticas de egress para cada job, de denegación por defecto o de permiso por defecto, con 24 presets de fuentes de software integrados, fuentes personalizadas tipadas y reglas explícitas de TLS, TCP, UDP e ICMP. Las políticas se validan antes de que empiece el job y, si fallan, bloquean. CRACI también ofrece un rango estable de IP de egress.

Procedencia y monitorización a partir del mismo registro

La API devuelve SBOM, trazas de red y procedencia. CRACI agrega las vulnerabilidades de todos los builds y repositorios y sigue reevaluando las SBOM monitorizadas.

Cuál le conviene

• Siga con CircleCI si su código está en GitLab o Bitbucket, si depende de builds en Windows, macOS o GPU, o si ejecuta jobs en su propio hardware.
• Considere CRACI si su código está en GitHub y está valorando GitHub Actions frente a CircleCI, y distribuye software en el que debe demostrar qué entró en cada lanzamiento.
• Use los dos durante una migración gradual: mantenga los pipelines de macOS y Windows en CircleCI y ejecute en CRACI los workflows Linux de GitHub Actions donde más importa la evidencia del build.

Para el Cyber Resilience Act

El Cyber Resilience Act de la UE espera que los fabricantes sepan qué contiene cada lanzamiento y gestionen sus vulnerabilidades, con obligaciones de notificación desde septiembre de 2026 y plena aplicación desde diciembre de 2027. En CircleCI, esa evidencia procede de los escáneres y orbs que usted conecte a sus pipelines. CRACI la genera a partir del registro del build y exporta las SBOM en CycloneDX o SPDX, vulnerabilidades incluidas. 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.

Migrar un pipeline a CRACI

CRACI ejecuta workflows de GitHub Actions, así que un pipeline de CircleCI necesita primero un equivalente en GitHub Actions. Una vez que lo tenga, instale la GitHub App de CRACI en su organización y defina la etiqueta del runner:

runs-on: craci

Las ejecuciones siguen apareciendo en la interfaz de GitHub. Los jobs disponen de Docker Engine, Buildx y Compose v2, tamaños de runner de 1 a 32 vCPU con 3 GB de RAM por vCPU y compatibilidad con la caché de GitHub Actions. Más información sobre la generación de SBOM durante el build, o consulte los precios y el programa para startups.