Seguridad de la cadena de suministro de software, registrada en cada build
Su cadena de suministro de software se encuentra con su producto en el build de CI. CRACI ejecuta sus jobs de GitHub Actions en runners seguros y registra cada dependencia que descargan, controla a qué puede acceder cada build y mantiene el seguimiento de las vulnerabilidades de lo que ha distribuido.
Runners seguros para GitHub Actions
Cambie runs-on a craci y sus jobs de GitHub Actions se ejecutarán en los runners de CRACI, con las ejecuciones visibles en GitHub como siempre. Cada job obtiene su propia máquina virtual aislada en Linux x86-64 o ARM64, alojada en Europa. Los builds se ejecutan aproximadamente el doble de rápido que en los runners alojados por GitHub, gracias a un hardware más rápido, colas más cortas y la caché.
Una SBOM registrada a partir de cada build
CRACI es un registrador, no un escáner. Un proxy que entiende de paquetes, situado en el runner, ve cada paquete que descarga el job de fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga de Yocto y OpenEmbedded, incluidos los paquetes restaurados desde cachés de CI. La SBOM de cada job incluye un estado de completitud y se exporta en CycloneDX o SPDX con las dependencias transitivas y la licencia declarada de cada componente.
Controle a qué puede acceder un build
Una política de salida decide a qué hosts puede conectarse un job: denegación o permiso por defecto, 24 presets 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 las infracciones generan una alerta. Una dependencia o un paso de build comprometido no puede enviar datos discretamente a un host que usted nunca aprobó.
Procedencia de lo que distribuye
La REST API pública devuelve SBOM, trazas de red y datos de procedencia de cada job, todo registrado a partir del mismo build. Las evidencias salen del propio build, sin ningún paso adicional en el workflow.
Seguimiento de vulnerabilidades después del lanzamiento
CRACI reevalúa de forma continua las SBOM de lo que ha distribuido a medida que se publican nuevas vulnerabilidades, y agrega los hallazgos de todos los builds y repositorios. Los equipos de seguridad los clasifican y asignan cada uno al equipo responsable de la corrección. Los controles de política pueden bloquear un build por hallazgos o por una licencia, VEX es compatible, las SBOM de los proveedores se monitorizan junto con sus propios builds, y la vista de inventario muestra qué versiones de software están desplegadas en qué productos.
Evidencias para clientes y auditores
Los clientes, los auditores y la normativa piden cada vez más una SBOM por versión y un registro de cómo se gestionaron las vulnerabilidades. CRACI exporta las SBOM en CycloneDX o SPDX, incluidas las vulnerabilidades encontradas en sus componentes, y una REST API pública devuelve SBOM, trazas de red y datos de procedencia. Las mismas evidencias sirven para el Cyber Resilience Act de la UE, NIS2, los requisitos de SBOM de la FDA y los controles de la cadena de suministro de ISO 27001.
Las preguntas que plantea un incidente en la cadena de suministro
Cuando se compromete un paquete, una acción de CI o un registro, las primeras horas se dedican a averiguar si le afecta. Estas son las preguntas que se hacen los equipos, y dónde las responde el registro del build de CRACI.
| La pregunta | Cómo la responde CRACI |
|---|---|
| ¿Ha descargado alguno de nuestros builds la versión comprometida del paquete? | La SBOM de cada build enumera los paquetes que el job descargó realmente, así que busca en los builds registrados en lugar de volver a escanear los repositorios. |
| ¿Qué productos y versiones nuestros están afectados? | Las SBOM monitorizadas se reevalúan de forma continua, y la vista de inventario relaciona las versiones de software con los productos en los que están desplegadas. |
| ¿Podría un paso del build haber enviado secretos a algún sitio? | La traza de red de cada job registra las conexiones que realizó, y la política de salida bloquea los hosts fuera de la política antes de que se llegue a ellos. |
| ¿Es esta SBOM lo bastante completa para entregarla? | La SBOM de cada job indica su completitud: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. |
| ¿Quién lo está corrigiendo y podemos demostrar que se gestionó? | Los hallazgos se clasifican y se asignan a los equipos responsables, y las SBOM se exportan en CycloneDX o SPDX con las vulnerabilidades encontradas en sus componentes. |
CRACI cubre el build y lo que distribuye. El análisis de código, la detección de secretos y el análisis de alcanzabilidad siguen en manos de sus herramientas de seguridad de aplicaciones. GitHub Actions es compatible hoy, con otros sistemas de CI en la hoja de ruta.
Seguridad de la cadena de suministro de software: respuestas
Qué abarca, por qué pertenece al CI/CD y qué papel desempeña CRACI
¿Qué es la seguridad de la cadena de suministro de software?
La seguridad de la cadena de suministro de software protege todo lo que entra en su software entre el primer commit y el lanzamiento: dependencias de código abierto, imágenes base, herramientas de build, acciones de CI de terceros, el propio pipeline de CI y los artefactos que distribuye. Consiste en saber cuáles son esas piezas, controlar de dónde proceden y demostrar qué entró en cada versión.
¿Por qué proteger la cadena de suministro de software en el CI/CD?
El build de lanzamiento es donde se resuelven, descargan y empaquetan sus dependencias. Un build de producción no es el build de un portátil: los rangos de versiones, las etiquetas mutables y las cachés hacen que pueda descargar algo distinto. Un registro tomado mientras se ejecuta el build de lanzamiento es el único registro fiable de lo que se distribuyó, y el runner del build es el lugar donde puede controlar a qué puede acceder el build.
¿En qué se diferencia CRACI de un escáner de seguridad de la cadena de suministro?
Los escáneres leen archivos a posteriori: un manifiesto, un lockfile, el código fuente o un binario terminado. CRACI es el runner de sus jobs de GitHub Actions, así que observa el build mientras ocurre y registra los paquetes que cada job descargó realmente, incluidos los restaurados desde cachés de CI. Cada SBOM indica su propia completitud, una política de salida controla a qué puede acceder el build y la API devuelve SBOM, trazas de red y datos de procedencia.
¿Sustituye CRACI mis workflows de GitHub Actions?
No. CRACI sustituye el runner, no GitHub Actions. Usted cambia runs-on a craci, y sus workflows, sus triggers y su historial de ejecuciones permanecen en GitHub.
¿Qué sistemas de CI y plataformas admite CRACI?
Hoy, GitHub Actions; otros sistemas de CI están en la hoja de ruta, entre ellos GitLab CI y Jenkins. Los runners son Linux en x86-64 y ARM64, con Windows y macOS en la hoja de ruta.
¿Hace CRACI SAST, detección de secretos o análisis de alcanzabilidad?
No. CRACI registra y controla el build, hace el seguimiento de las vulnerabilidades de lo que distribuye y genera las evidencias. Analizar su propio código en busca de fallos o secretos, y el análisis de alcanzabilidad, son tareas de una herramienta de seguridad de aplicaciones.
¿Dónde se almacenan los datos de mis builds?
CRACI está alojado en Europa, sobre infraestructura bare metal europea, y los datos se conservan 180 días por defecto, con retención personalizada en Enterprise. CRACI no almacena su código fuente. CRACI cuenta con la certificación ISO 27001; encontrará los detalles en el Trust Center.
Vea lo que descargan realmente sus builds
Reserve una demo para ver la SBOM, la traza de red, la política de salida y los datos de procedencia que CRACI registra para un build de GitHub Actions
Reservar una demo