Qué sustituye CRACI en su stack y qué complementa

La respuesta corta: qué cambia y qué se queda

Analice su propio stack con esta tabla. Cada fila es una tarea que hoy hace una herramienta de su stack, lo que esa tarea necesita ver para hacerse y si CRACI la hace desde el lugar que ocupa.

Tarea en su stack	Lo que la tarea necesita ver	CRACI	Lo que conserva, y por qué
Runners de CI para jobs de Linux en GitHub Actions: alojados en GitHub, de un proveedor externo de runners o una flota autoalojada	Un lugar donde ejecutar el job	Sustituye	Runners para Windows, macOS, GitHub Enterprise Server y sistemas de CI distintos de GitHub Actions, que CRACI no admite hoy
Monitorización de red o agentes de egress añadidos a los runners que conserva	El tráfico saliente del job	Sustituye en runners de CRACI	Agentes en los runners que conserva en otro lugar
Generadores de SBOM ejecutados en CI, equipo por equipo: escáneres de manifiestos, lockfiles o imágenes usados para producir SBOM	Lo que el build descargó realmente	Sustituye para builds en CRACI	Generadores para el software que no compila en CRACI, como imágenes que descarga y nunca compila
Generación de SBOM integrada en Yocto (create-spdx) para la cobertura de la cadena de suministro	Cada fuente y herramienta que descargó el build de BitBake	Sustituye para la cobertura de la cadena de suministro	create-spdx, si depende de sus metadatos de recetas: parches aplicados y CVE marcadas como corregidas
Seguimiento de vulnerabilidades a partir de SBOM: subir SBOM, cotejar avisos, vigilar los nuevos	Una SBOM precisa por versión, siempre actualizada	Sustituye para builds en CRACI; se pueden añadir SBOM de proveedores	Una herramienta específica si necesita lo que CRACI no hace: reachability, métricas de remediación como MTTR o plazos por severidad
SBOM y listas de componentes guardadas en hojas de cálculo	Una SBOM precisa por versión, siempre actualizada	Sustituye	Nada
Comprobación de licencias declaradas y política de licencias	La licencia declarada de cada componente	En parte	Escaneo de licencias de texto completo y a nivel de fragmento, avisos de atribución
SAST y escaneo de código	Su código fuente	Complementa	Consérvelo; se ejecuta sin cambios como paso del workflow en un runner de CRACI
Escaneo de secretos y push protection	Su repositorio y sus commits	Complementa	Consérvelo
DAST y pruebas de API	Su servicio en ejecución	Complementa	Consérvelo
Análisis de binarios y firmware de terceros	Un binario terminado que usted no compiló	Complementa	Consérvelo
Escaneo de fragmentos y firmas para código copiado o vendorizado	El contenido de los archivos del repositorio	Complementa	Consérvelo
Priorización basada en reachability	Su grafo de llamadas	Complementa	Consérvela si depende de ella
Escaneo de IaC, clústeres y configuraciones erróneas	La configuración y la infraestructura en ejecución	Complementa	Consérvelo
Comprobaciones de postura de CI/CD sobre la configuración de los workflows	Archivos y ajustes de workflows	Complementa	Consérvelas
Ticketing, gestión de casos de PSIRT, publicación de avisos	Su proceso	Complementa	Consérvelos
Automatización del cumplimiento: recopilación de evidencias para auditorías SOC 2 o ISO 27001	Sus controles en todos los sistemas	Complementa	Consérvela; los registros de CRACI son evidencias que puede recopilar

El antes y el después

Antes: runners alojados en GitHub, un generador de SBOM distinto en el workflow de cada equipo, el create-spdx de Yocto alargando el build y SBOM subidas a un tracker o a una hoja de cálculo, con escaneo de código, escaneo de secretos, análisis de binarios y ticketing a su alrededor. Después: runners de CRACI que ejecutan cada job, aplican su política de egress, registran su SBOM y la mantienen monitorizada. Las herramientas que leen código, repositorios, binarios y su proceso no cambian.

Qué sustituye CRACI, y por qué

Cada una de estas tareas se realiza durante el build. CRACI puede asumirlas porque es donde se ejecuta el build. Para cada una: el mecanismo, a qué renuncia y un ejemplo.

Sus runners

CRACI es un runner para GitHub Actions. Usted cambia runs-on a craci y las ejecuciones siguen apareciendo en GitHub como cualquier otro job de Actions. Cada job obtiene su propia máquina virtual, en Linux x86-64 o ARM64, con un tamaño de 1 a 32 vCPU, medida por segundos. No hay que reescribir workflows: sus pasos actuales, incluidos los de escaneo, siguen ejecutándose.

CRACI solo cobra por los minutos de build: $0.002 por vCPU-minuto ($0.004 para un runner predeterminado de 2 vCPU), medidos por segundos, sin cuota mensual ni cargo por SBOM. Eso lo convierte en uno de los runners de CI más asequibles. Ejecuta los builds aproximadamente el doble de rápido que los runners alojados en GitHub, gracias a un hardware más rápido, tiempos de cola más cortos y el uso de caché.

Runner, por minuto	CRACI	Alojado en GitHub	Diferencia
2 vCPU x64	$0.004	$0.006	CRACI aproximadamente un 33% más barato
2 vCPU ARM64	$0.004	$0.005	CRACI un 20% más barato
32 vCPU x64	$0.064	$0.082	CRACI aproximadamente un 22% más barato
32 vCPU ARM64	$0.064	$0.050	CRACI un 28% más caro

Precios de lista de GitHub a septiembre de 2026. GitHub redondea cada job al minuto completo superior; CRACI mide por segundos. Ejemplo: un build de 10 minutos en un runner x64 de 2 núcleos alojado en GitHub cuesta $0.060. Con aproximadamente el doble de velocidad, tarda 5 minutos en un runner de CRACI de 2 vCPU y cuesta $0.020, aproximadamente un 67 % menos. Consulte precios y precios de runners de CI.

A qué renuncia. Los runners de Windows y macOS, otros sistemas de CI y los runners alojados por el cliente no están disponibles hoy; GitLab CI, Jenkins, Windows, macOS y los runners alojados por el cliente están en la hoja de ruta. GitHub Enterprise Server no es compatible. Los runners son gestionados, sobre infraestructura europea. Si está comparando runners gestionados con su propia flota, consulte runners gestionados frente a autoalojados.

Agentes de egress en los runners que conserva

Un agente de egress vigila o limita el tráfico de un runner que opera otra parte. En CRACI es el propio runner quien aplica la política de egress: denegar o permitir por defecto, 24 preajustes integrados de fuentes de software, fuentes personalizadas tipadas para registros de paquetes y Git, y reglas de red explícitas. La política se valida antes de que empiece el job y falla en modo cerrado, y CRACI alerta de las infracciones de la política. En los runners de CRACI no hace falta un agente aparte.

Ejemplo: una dependencia comprometida intenta enviar los secretos del job a un host que el build nunca ha necesitado. Con una política de denegación por defecto, la conexión se bloquea, incluso en un ataque que nadie ha visto antes, porque la política solo permite lo que el build necesita en lugar de buscar hosts maliciosos conocidos.

A qué renuncia. La política cubre los jobs en runners de CRACI. Los runners que conserve en otro lugar siguen necesitando su propio control.

El generador de SBOM en el workflow de cada equipo

Un generador lee los archivos que tiene delante, como un manifiesto, un lockfile o una imagen, y reconstruye lo que se incluyó. Generadores distintos devuelven listas distintas a partir del mismo checkout, y los equipos suelen elegir el suyo, así que la organización acaba con varios inventarios que no coinciden.

CRACI registra los paquetes que cada job descargó realmente, incluidos los restaurados desde cachés de CI, y las dependencias ocultas que las herramientas basadas en lockfiles pasan por alto: código descargado por hooks de npm install, scripts de build de Rust que descargan durante el build, y la imagen base con sus capas de sistema operativo en un build de contenedores. Cada componente de la SBOM estuvo en el build. La SBOM de cada job indica su completitud, como Complete, Complete with connections, Incomplete, Unavailable o Not recorded, de modo que una laguna queda a la vista en lugar de pasar desapercibida. El resultado es un único inventario para cada repositorio que se compila en CRACI, exportado en CycloneDX o SPDX. Ecosistemas que se registran hoy: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk y fuentes Git, además de descargas de Yocto y OpenEmbedded.

Ejemplo: expressjs/express 5.2.1 no incluye ningún lockfile en el repositorio. Un generador que resuelve dependencias a partir de lockfiles no tiene nada que resolver ahí, y aun así puede devolver un documento que no incluye ninguna de las dependencias de npm declaradas en package.json. Un build del mismo proyecto en CRACI registra los paquetes que descargó npm install. Más sobre el método en SBOM generadas durante el build y comparativa de herramientas SCA y SBOM; para una pila de generadores hecha por uno mismo, consulte la pila de SBOM DIY.

A qué renuncia. A los ecosistemas que CRACI aún no registra. Maven y Java están en la hoja de ruta, y todo lo que no figura en la lista anterior no está cubierto. Conserve un generador para esos builds.

La generación de SBOM integrada en Yocto

Yocto escribe su propia SBOM SPDX mediante create-spdx, y es exhaustiva con lo que compila BitBake. No puede ver lo que ocurre fuera de los metadatos de BitBake. CRACI ejecuta el build de BitBake y registra lo que descargó. En un build comparativo de core-image-sato en un runner ARM64 nativo con 32 vCPU, la SBOM de CRACI tenía todos los componentes que tenía la SBOM de Yocto, más 88 que esta pasó por alto: 23 paquetes del host en la máquina de build, 10 fuentes de GitHub, entre ellas la GitHub Action actions/upload-artifact, y 55 fuentes y herramientas más descargadas durante el build. Registró las 653 versiones de crates de Rust con package URL pkg:cargo, de modo que se pueden cotejar con los avisos. El build sin la generación de SBOM de Yocto tardó un 43 % menos: aproximadamente $9.96 frente a $5.68 por build al precio de CRACI.

A qué renuncia. El SPDX de Yocto incluye metadatos de recetas que CRACI no registra: los parches aplicados y las CVE marcadas como corregidas. Si depende de ellos, mantenga create-spdx activado. El método y la comparación completa están en builds de Yocto en CRACI.

Convertir las SBOM en seguimiento de vulnerabilidades

Un tracker independiente necesita que le suministren una SBOM y se fía de lo que recibe. CRACI produce la SBOM y conserva el registro. Las SBOM monitorizadas se reevalúan continuamente a medida que se publican nuevos avisos. El historial de builds muestra qué builds contenían una dependencia vulnerable, directa o transitiva, de modo que usted sabe durante qué periodo estuvo afectado, dentro de la retención de su plan. Los hallazgos se asignan al equipo responsable de la corrección, CRACI notifica a las personas pertinentes una vulnerabilidad y su severidad, y las puertas de política pueden bloquear un build por hallazgos, incluido un build que contenga una CVE concreta. Se admite VEX. Se pueden añadir SBOM de proveedores, de modo que los componentes adquiridos se monitorizan junto con sus propios builds.

Ejemplo: se publica un aviso para un crate que uno de sus servicios compiló hace tres meses. CRACI lo coteja con todas las SBOM monitorizadas y muestra qué builds contenían esa versión, sin que nadie tenga que volver a subir nada.

A qué renuncia. CRACI no ofrece análisis de reachability ni métricas de remediación como MTTR, plazos por severidad o tendencias del backlog. Si depende de ellas, conserve la herramienta que las proporciona. Consulte seguimiento de vulnerabilidades para ver la funcionalidad completa.

La hoja de cálculo

Para los equipos sin herramientas de SBOM, lo que sustituye CRACI es el montaje manual: alguien copia listas de dependencias en una hoja de cálculo antes de una versión o una auditoría. Un build en CRACI produce la SBOM como efecto secundario de su ejecución, así que la lista existe para cada build, no solo para aquellos de los que alguien se acordó.

Qué complementa CRACI, y cómo

Estas herramientas leen cosas que CRACI nunca lee. CRACI no lee su código fuente en busca de fallos, no prueba servicios en ejecución ni analiza binarios que no ha compilado. Siguen funcionando como hasta ahora.

Herramientas que leen su código y su repositorio

SAST, el escaneo de secretos y push protection, el escaneo de fragmentos y firmas, el escaneo de IaC y las comprobaciones de postura de CI/CD inspeccionan su código, sus commits o su configuración. Los pasos de su workflow se ejecutan sin cambios en un runner de CRACI, y las funciones a nivel de repositorio no se ven afectadas porque nunca se ejecutaron en el runner. Un paso de escaneo de código puede estar en el mismo job que su build. SAST queda fuera del alcance por decisión propia: hay muchas herramientas SAST excelentes que funcionan junto con CRACI. Consulte SAST frente a SCA para ver en qué se diferencian los dos tipos de hallazgo.

Herramientas que inspeccionan lo que usted no compiló

El análisis de binarios y firmware de proveedores, los escáneres de imágenes que descarga pero nunca compila y DAST sobre servicios en ejecución examinan algo que se compiló en otro lugar o que ya está en ejecución. CRACI registra builds; un binario que llega de un proveedor se compiló en un lugar que CRACI nunca vio. Si el proveedor le entrega una SBOM, CRACI puede monitorizarla junto con sus propios builds.

La priorización basada en reachability lee su grafo de llamadas, que CRACI no analiza. Consérvela si depende de ella; consulte análisis de reachability para saber lo que puede y no puede decirle.

Sistemas de proceso

El ticketing, la gestión de casos de PSIRT, la publicación de avisos y las plataformas de automatización del cumplimiento gestionan su proceso a través de muchos sistemas. CRACI dirige los hallazgos al equipo responsable y guarda las evidencias del build; conserve sus herramientas de proceso para lo demás. Los registros salen de CRACI como SBOM en CycloneDX o SPDX y a través de la API, que devuelve SBOM, trazas de red y datos de procedencia. Para la parte de auditoría, consulte comprobaciones de SBOM para SOC 2. Para el trabajo de licencias más allá de las licencias declaradas, como avisos y revisión del texto completo, consulte cumplimiento de licencias de código abierto. CRACI incluye la licencia declarada de cada componente y aplica reglas de política de licencias, incluido el bloqueo de un build por una licencia.

Cómo encontrar el punto de sustitución en su propio stack

Cinco preguntas que puede responder en una tarde. Cada respuesta le indica si una línea de su stack cambia.

1. ¿Sus builds se ejecutan en GitHub Actions sobre Linux? Si es así, los runners cambian. Si no, CRACI no sustituye nada hoy.
2. ¿Quién genera hoy las SBOM y cuántos generadores distintos se usan? Cada generador de un repositorio que traslade a CRACI es una línea que desaparece.
3. ¿Compila imágenes de Yocto? Si es así, compruebe si alguien depende de los parches aplicados y las CVE corregidas de la salida de create-spdx antes de desactivarlo.
4. ¿Adónde van las SBOM una vez generadas: a un tracker, a una hoja de cálculo, a ninguna parte? Esa herramienta o ese proceso es la segunda línea que desaparece, salvo que necesite de ella reachability o métricas de remediación.
5. ¿Cuáles de sus herramientas de seguridad leen código, repositorios o binarios de terceros? Esas se quedan. Anótelas, para que nadie espere que CRACI las sustituya.

Un ejemplo práctico

Un fabricante de dispositivos ilustrativo, no basado en ninguna empresa real: builds de Linux en runners alojados en GitHub, dos equipos que usan dos generadores de SBOM distintos, una línea de productos Yocto con create-spdx activado, SBOM reunidas en una hoja de cálculo compartida, una suite de escaneo de código y un sistema de ticketing. Su equipo de seguridad responde que sí a las preguntas 1 y 3, encuentra dos generadores en la pregunta 2 y una hoja de cálculo en la pregunta 4, y enumera el escaneo de código, el escaneo de secretos y el sistema de ticketing en la pregunta 5. Nadie usa los metadatos de parches del SPDX de Yocto.

Pasa a CRACI	Se queda
Runners alojados en GitHub para los jobs de Linux	Escaneo de código, ejecutado como paso en runners de CRACI
Los dos generadores de SBOM	Escaneo de secretos
create-spdx, ya que nadie necesita sus metadatos de parches	El sistema de ticketing
La hoja de cálculo de SBOM

En la línea de los runners, un build de 10 minutos que cuesta $0.060 en un runner x64 de 2 núcleos alojado en GitHub cuesta aproximadamente $0.020 en CRACI con la aceleración. Los costes de las demás herramientas los debe completar la propia empresa.

Cuándo CRACI no es la respuesta

• Sus pipelines se ejecutan en GitLab CI, Jenkins, Azure DevOps u otro sistema de CI. CRACI solo admite GitHub Actions hoy, con GitLab CI y Jenkins en la hoja de ruta, así que todavía no sustituye nada.
• Sus builds necesitan runners de Windows o macOS o GitHub Enterprise Server, o deben ejecutarse en su propia infraestructura.
• Su principal problema es el ruido del escaneo de código en su propio código. Eso es un problema de ajuste de SAST; consulte SAST frente a SCA y cómo reducir el ruido de vulnerabilidades.
• Su principal riesgo es el firmware y los binarios que recibe de proveedores, no el código que compila.
• Su stack es sobre todo Java y Maven, que están en la hoja de ruta, o .NET, que no figura en la lista de ecosistemas que registra CRACI.
• Necesita hoy priorización basada en reachability o gestión de casos de PSIRT.

Para ver el producto paso a paso, consulte cómo funciona CRACI; para la SBOM en sí, generación de SBOM.

Qué sustituye CRACI: preguntas frecuentes

¿Qué sustituye CRACI?

Sus runners de GitHub Actions para jobs de Linux, los generadores de SBOM que los equipos ejecutan en CI para los builds que pasan a CRACI, el create-spdx de Yocto para la cobertura de la cadena de suministro, los agentes de egress en los runners y el seguimiento independiente de vulnerabilidades a partir de SBOM para esos builds. No sustituye las herramientas que leen su código, sus repositorios o binarios de terceros.

¿CRACI es un complemento de nuestra herramienta SCA o sustituye algo?

Sustituye tareas en la capa de build: el runner, la generación de SBOM y el seguimiento que se deriva de la SBOM. Que eso desplace a su herramienta SCA depende de para qué la use. Si lee su código, hace análisis de fragmentos o de binarios o le ofrece reachability, esas partes se quedan.

¿Seguimos necesitando nuestro generador de SBOM si ejecutamos los builds en CRACI?

No para los builds que se ejecutan en CRACI y usan los ecosistemas que registra. CRACI registra los paquetes que descargó cada job y exporta la SBOM en CycloneDX o SPDX. Conserve un generador para el software que no compila en CRACI, como las imágenes que descarga, y para los ecosistemas que CRACI aún no registra, como Maven.

¿Seguimos necesitando la generación de SBOM integrada en Yocto (create-spdx)?

Para la cobertura de la cadena de suministro, no: en un build comparativo de core-image-sato, la SBOM de CRACI tenía todos los componentes que tenía la de Yocto, más 88 que esta pasó por alto, y el build sin create-spdx tardó un 43 % menos. Mantenga create-spdx activado si depende de sus parches aplicados y CVE marcadas como corregidas, que CRACI no registra.

¿CRACI sustituye el escaneo de código o el escaneo de secretos?

No. CRACI no lee su código fuente ni sus commits en busca de fallos o secretos. Conserve esas herramientas. Los pasos de escaneo de código se ejecutan sin cambios en su workflow en un runner de CRACI, y las funciones a nivel de repositorio no se ven afectadas.

¿CRACI sustituye el análisis de binarios o de firmware?

No. CRACI registra los builds que ejecuta. Para el firmware y los binarios que recibe de proveedores, el análisis de binarios es la herramienta adecuada. Si un proveedor le entrega una SBOM, CRACI puede monitorizarla junto con sus propios builds.

¿Podemos mantener nuestros pasos de seguridad actuales en GitHub Actions en runners de CRACI?

Sí. CRACI sustituye el runner, no GitHub Actions: usted configura runs-on como craci y sus workflows, pasos y resultados se quedan en GitHub. Los pasos de escaneo, de pruebas y cualquier otro paso siguen ejecutándose como antes.