Ciberresiliencia automatizada para desarrolladores y agentes
Convierta cada build en su primera línea de defensa.
Sitúe la seguridad de la cadena de suministro en el centro de su software con runners rápidos y fiables que cuestan menos.
- Runners seguros
- SBOM generadas durante el build
- Monitorización de vulnerabilidades
- Respuesta a vulnerabilidades
- 185 paquetes registrados
- 6 conexiones rechazadas
- SBOM completa
- Corregido en v2.4.1
- Build
northwind-controls/web-portal
- Paquetes
- next 15.2.2
- react 19.0.0
- react-dom 19.0.0
- express 4.21.2
- tailwindcss 4.0.14
- typescript 5.8.2
- Control de políticaBuild #1843 detenido Build #1844 superado
- Artefacto publicado
ghcr.io/northwind-controls/web-portal:2.4.1
Publicado como v2.4.1
Equipos que construyen con CRACI
Las vulnerabilidades llegan más rápido que cualquier corrección.
A los atacantes les basta con una vía de entrada, y los agentes les ayudan a encontrarla más rápido que nunca. Su equipo tiene que cerrar cada brecha, casi siempre a mano.
2026 hasta ahora
- CVE publicadas al día
- 293
- Una cada 5 minutos, de media.
- Más al día que el año anterior
- +124%
- Frente a la media diaria de 2025.
- Con calificación High o Critical, cada día
- 148
- Según su puntuación CVSS.
| Año | CVE al día | High o Critical al día |
|---|---|---|
| 2020 | 39 | 7 |
| 2021 | 54 | 12 |
| 2022 | 68 | 20 |
| 2023 | 78 | 28 |
| 2024 | 109 | 48 |
| 2025 | 131 | 54 |
| 2026 hasta ahora | 293 | 148 |
Por qué ahora
- Las alertas se han convertido en ruido.
Cuando cientos de hallazgos son urgentes, ninguno lo es. Los equipos dejan de gestionar el riesgo y se ponen a contar alertas.
- El volumen supera a cualquier equipo.
La clasificación y las correcciones se siguen haciendo a mano. Con este volumen, contratar a más personas no cierra la brecha.
- Las correcciones compiten con las funciones.
A los equipos de producto se les mide por las funciones que entregan, así que el trabajo de seguridad espera un sprint tranquilo que nunca llega.
- Los escáneres solo hacen estimaciones.
Una lista deducida de los archivos después del build pasa por alto lo que entró realmente, y la falsa confianza hace que nadie siga buscando.
Su software toma forma durante el build.
Su lockfile fija lo que debería instalarse. El build decide lo que llega realmente. CRACI registra cada paquete a medida que entra, con la versión resuelta, su procedencia y si se restauró desde una caché de CI.
"packages": {
…
…
}| Paquete | Resuelto | Entró vía | Fuente |
|---|---|---|---|
| Vía package.json | |||
| express vía package.json | 4.21.2 | package.json | registry.npmjs.org |
| next vía package.json Ahora afectado por CVE-2025-29927 · Critical | 15.2.2 | package.json | registry.npmjs.org |
| react vía package.json · desde la caché de CI | 19.0.0 | package.json | Caché de CI |
| react-dom vía package.json · desde la caché de CI | 19.0.0 | package.json | Caché de CI |
| styled-jsx vía next | 5.1.6 | next | registry.npmjs.org |
| Vía script de build | |||
| tailwindcss vía script de build | 4.0.14 | script de build | registry.npmjs.org |
| typescript vía script de build | 5.8.2 | script de build | registry.npmjs.org |
| y 178 paquetes registrados más | |||
Proteja el build. Registre sus dependencias.
Sus jobs se ejecutan en runners de CRACI en lugar de en los alojados por GitHub, el doble de rápido. Cada paquete que descargan se registra con su versión, su fuente y su licencia. Todo lo que procede de una fuente ajena a su política se rechaza.
Secure Build Service
Cada job se ejecuta en su propia máquina virtual aislada, tras una política de salida que se comprueba antes de que empiece el job.
- VM aislada
- Salida denegada por defecto
- Falla en modo cerrado
- Alerta ante infracciones
Package Analytics
Un proxy que entiende de paquetes registra cada paquete que descarga un job, con su versión resuelta, su fuente y su licencia declarada.
- npm
- PyPI
- RubyGems
- Cargo
- Go
- Nix
- OCI
- Yocto
- y más
- time2025-03-14 09:13:07 UTC
- jobrelease.yml #1842
- stepnpm run build
- policyDefault deny. Allowed: npm, GitHub, ghcr.io, Docker Hub, example.com
- denied malicious.example:443
- reasonEl host no está en la política
- actionBloqueado en el runner
{
"bomFormat": "CycloneDX",
"specVersion": "1.7",
…
"components": [{
"name": "next",
"version": "15.2.2",
"purl": "pkg:npm/[email protected]",
"licenses": [
{ "license": { "id": "MIT" } }
]
}, …]
}CRACI ve el tráfico que los escáneres no ven.
Otras herramientas de SBOM leen el lockfile o el resultado del build y deducen lo que se incluyó. CRACI ve lo que entra realmente en cada build, incluidas las dependencias ocultas que descargan los hooks durante el build, los scripts de build y las imágenes base.
Escáner
Escáner de la competencia
- Método
- Lee package-lock.json
- Cuándo
- Después del build
- Ve
- Lo que enumera el lockfile
| Paquete | Versión | Licencia | Encontrado en |
|---|---|---|---|
| next pkg:npm/[email protected] | 15.2.2 | MIT | package-lock.json |
| react pkg:npm/[email protected] | 19.0.0 | MIT | package-lock.json |
| react-dom pkg:npm/[email protected] | 19.0.0 | MIT | package-lock.json |
| express pkg:npm/[email protected] | 4.21.2 | MIT | package-lock.json |
| styled-jsx pkg:npm/[email protected] | 5.1.6 | MIT | package-lock.json |
| No figura en ningún lockfile, así que tampoco en la SBOM | |||
| No figura en ningún lockfile, así que tampoco en la SBOM | |||
| No figura en ningún lockfile, así que tampoco en la SBOM | |||
142 paquetes enumerados 43 ausentes
SBOM registrada
- Método
- Ve el tráfico del build
- Cuándo
- Durante el build
- Ve
- Lo que descargó el build
| Paquete | Versión | Licencia | Descargado de |
|---|---|---|---|
| next pkg:npm/[email protected] | 15.2.2 | MIT | registry.npmjs.org |
| react pkg:npm/[email protected] | 19.0.0 | MIT | registry.npmjs.org |
| react-dom pkg:npm/[email protected] | 19.0.0 | MIT | registry.npmjs.org |
| express pkg:npm/[email protected] | 4.21.2 | MIT | registry.npmjs.org |
| styled-jsx pkg:npm/[email protected] | 5.1.6 | MIT | registry.npmjs.org |
| binario precompilado oculto vía hook postinstall · pkg:npm/hidden-package | — | — | registry.npmjs.org |
| 2 descargas del script de build oculto vía script de build · pkg:generic/[email protected]?download_url=example.com/tool | — | — | example.com |
| 40 paquetes del SO de la imagen base oculto vía Dockerfile FROM · pkg:oci/ubuntu | — | — | registry.hub.docker.com |
185 paquetes registrados 43 más de los que muestra el lockfile
Build de ejemplo. Arrastre el separador para comparar. Cómo funcionan las SBOM generadas durante el build
Localice las posibles vulnerabilidades en las versiones exactas.
CRACI comprueba de forma continua las SBOM registradas en busca de nuevas vulnerabilidades. En este ejemplo ilustrativo, se divulga una vulnerabilidad crítica 7 días después del lanzamiento. Siga el registro del build desde el paquete afectado hasta la corrección del equipo.
Paso 1 de 4
Se divulga CVE-2025-29927
next es una dependencia directa, y el build #1842 registró la versión exacta.
- Gravedad
- Critical 9.1
- Paquete
- next
- Afectado
- 15.0.0 a 15.2.2
- Corregido en
- 15.2.3
Paso 2 de 4
Una versión está afectada
CRACI la coteja con la SBOM registrada.
- Versión
- web-portal v2.4.0
- Coincidencia
- next 15.2.2, dependencia directa
- SBOM
- Complete
Paso 3 de 4
Se distribuyó como esta imagen
La versión, su imagen y su SBOM permanecen juntas.
- Imagen
- ghcr.io/northwind-controls/web-portal:2.4.0
- Versión
- v2.4.0
- SBOM
- En seguimiento
Paso 4 de 4
La corrección tiene un responsable
Clasifíquela, asígnela y sígala hasta una versión corregida.
- Responsable
- Equipo de plataforma
- Acción
- Actualizar next a 15.2.3 y volver a compilar
- Corregido en
- web-portal v2.4.1, 2025-03-22
Responda a cada auditor con pruebas.
Cada build deja evidencias: SBOM, registros de vulnerabilidades y cómo llegó cada corrección a una versión. Utilícelas en sus procesos de CRA, NIS2, ISO 27001 y SOC 2, para que la pregunta de un auditor se resuelva con una descarga y no con un proyecto.
- Composición
- Una SBOM generada durante el build para cada versión.
- CycloneDX
- SPDX
- Dependencias transitivas
- Vulnerabilidades
- Licencias declaradas
- Gestión de vulnerabilidades
- Las SBOM registradas se reevalúan de forma continua.
- Clasificación
- Corrección
- Junto a la versión
- Notificación
- CRACI presenta las notificaciones en su nombre.
- Alerta temprana
- Notificación
- Informe final
Cyber Resilience Act
- Se aplican las obligaciones de notificación
- El reglamento se aplica en su totalidad
Notificación de vulnerabilidad Extracto
web-portal v2.4.0
northwind-controls/web-portal · build #1842
- SBOM
- CycloneDX · Complete
- Build
- #1842 · commit 9f3c2e1
- Vulnerabilidad
- CVE-2025-29927 · Critical
- Componente
- next 15.2.2
- Se notifica a
- CSIRT y ENISA, a través de la plataforma única de notificación del CRA
Cronología de la gestión
- Versión compilada y SBOM registrada
- Aviso publicado y cotejado con esta versión
- Clasificada por Seguridad de producto, asignada a Equipo de plataforma
- v2.4.1 publicada con next 15.2.3
La SBOM se exporta en CycloneDX o SPDX
Ejecute su primer build en 5 minutos.
En esta demo llevamos un sitio de TanStack Start desde el registro hasta su primera ejecución en CRACI. Conectamos GitHub, dirigimos los jobs con runs-on: craci y observamos la primera ejecución. CRACI registra cada dependencia externa que descarga el build, señala las vulnerabilidades conocidas y rastrea cada una hasta el job que la introdujo.
From sign-up to your first build on CRACI
CRACI en YouTube: CRACI demo.
Vea cómo encaja CRACI en su flujo de entrega.
CRACI sustituye el runner, no GitHub Actions. Sus workflows, revisiones y pasos de despliegue siguen como están.
-
Conecte la GitHub App
En todos los repositorios o solo en los que elija.
-
Cambie su runner
Indique
runs-on: cracien el workflow. No cambia nada más. -
Ejecute su próximo build
Las ejecuciones siguen apareciendo en GitHub. El registro del build y la SBOM aparecen en CRACI.
- Runners
- Runners Linux gestionados en x86-64 y ARM64, sobre infraestructura europea.
- Builds
- Docker Engine, Buildx y Compose v2. Los builds de Yocto y BitBake están documentados.
- Su código y sus datos
- CRACI procesa el código fuente durante el build y no lo almacena. Los datos de los builds se alojan en Europa. El contenido de la caché depende de lo que guarden sus workflows. Lea la página de seguridad.
- En la hoja de ruta
- GitLab, Jenkins y otros sistemas de CI, runners de Windows y macOS, runners on-premise, Maven y Java.
Lo que preguntan los equipos antes de una demo
Compatibilidad, configuración, seguridad y tratamiento de datos.
¿Qué entornos de CI y ecosistemas de paquetes son compatibles?
GitHub Actions es hoy la integración de CI compatible, y otros sistemas de CI están en la hoja de ruta. CRACI registra los paquetes de los registros de npm, PyPI, RubyGems, Cargo, Go, Nix y OCI y de los repositorios de paquetes de Debian, Ubuntu y Alpine, además de las descargas de Git y otras fuentes. Maven y Java están en la hoja de ruta. Los runners son Linux en x86-64 y ARM64.
¿Qué hace falta para configurarlo?
Usted conecta la GitHub App de CRACI en todos los repositorios o en los que elija, e indica runs-on: craci en su workflow. CRACI sustituye el runner, no GitHub Actions, así que sus ejecuciones siguen apareciendo en GitHub.
¿A qué datos accede CRACI y dónde se almacenan?
La GitHub App lee su código y sus ejecuciones de Actions, y gestiona los runners que registra para su organización. CRACI procesa el código fuente durante el build y no lo almacena. Los datos de los builds, incluidos metadatos, datos de paquetes, trazas de red, SBOM, procedencia, cachés y registros de auditoría, se alojan en Europa, con retención personalizada en Enterprise. El contenido de la caché depende de lo que guarden sus workflows. Más información sobre seguridad y tratamiento de datos.
¿CRACI bloquea o alerta? ¿Qué ocurre con un build que incumple una política?
La política de salida se aplica en el runner. Se valida antes de que empiece el job y falla en modo cerrado, de modo que una conexión fuera de la política se rechaza y usted recibe una alerta. Los controles de política también pueden detener un build en tiempo real.
¿En qué formatos puedo exportar?
Las SBOM se exportan en CycloneDX o SPDX, con las dependencias transitivas, las vulnerabilidades y las licencias declaradas.
¿Qué está disponible hoy y qué está en la hoja de ruta?
Disponible hoy: runners Linux gestionados para GitHub Actions, SBOM generadas durante el build con vulnerabilidades, política de salida, monitorización continua de vulnerabilidades con clasificación y controles de política. En la hoja de ruta: GitLab, Jenkins y otros sistemas de CI, runners de Windows y macOS, y runners on-premise.
Con el respaldo de
Han hablado de nosotros
Vea el camino del build a la corrección.
- Explore las dependencias registradas durante un build.
- Identifique las versiones afectadas por una vulnerabilidad.
- Siga la respuesta desde la clasificación hasta una versión corregida.