124% más CVE notificadas al día en 2026 que el año pasado.

Plataforma

Cómo funciona CRACI

CRACI ejecuta sus builds de GitHub Actions y registra lo que descarga cada uno. Todo lo demás, desde el seguimiento de vulnerabilidades hasta las evidencias del CRA, se construye sobre ese registro.

Actualizado el

Visión general de la plataforma CRACI. El código fuente en GitHub pasa por GitHub Actions al CRACI Secure Build Service. El build alimenta CRACI Package Analytics y, a continuación, Vulnerability Analysis (que también recibe datos de proveedores externos), Digital Inventory y Compliance Reporting, que informa a terceros como clientes, proveedores y ENISA. El build también alimenta CRACI Attack Prevention. Tanto Attack Prevention como Digital Inventory conducen al despliegue en staging y producción.
La plataforma CRACI, de izquierda a derecha. Abrir el diagrama a tamaño completo.

En resumen

La mayoría de las herramientas de seguridad examinan su código o sus manifiestos a posteriori y deducen lo que probablemente contenía un build. CRACI es el runner del build, así que ve lo que el build descargó realmente, en el momento en que lo descargó. Ese registro es la base de todo lo que aparece en el diagrama: análisis de paquetes, prevención de ataques, análisis de vulnerabilidades, trazabilidad y generación de informes de cumplimiento.

Usted conserva GitHub y GitHub Actions. El cambio es una línea en cada workflow:

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

Paso a paso

1. Código fuente y CI/CD: GitHub y GitHub Actions

Su código permanece en GitHub. Conecta su organización instalando la GitHub App de CRACI, en todos los repositorios o solo en los que elija. Los workflows siguen ejecutándose desde GitHub Actions y sus ejecuciones siguen apareciendo en GitHub. GitHub Actions es hoy la integración de CI compatible; la compatibilidad con otros sistemas de CI/CD está en la hoja de ruta.

2. Build: CRACI Secure Build Service

Los jobs se ejecutan en runners de CRACI, en máquinas virtuales aisladas. Los runners escalan de 1 a 32 unidades de cómputo (1 vCPU y 3 GB de RAM cada una), en x86-64 y ARM64 nativos, con una imagen de Ubuntu compatible con GitHub o con las imágenes ligeras de CRACI. El uso se mide por segundos.

Los builds en CRACI se ejecutan aproximadamente el doble de rápido que en los runners alojados estándar de GitHub. Además, cada minuto cuesta menos: un runner Linux estándar de 2 vCPU cuesta $0.004 por minuto, frente a los $0.006 de GitHub (alrededor de un 33% menos). En conjunto, un build que tarda 10 minutos en GitHub termina en unos 5 en CRACI y cuesta alrededor de un 67% menos. CRACI también factura por segundo en lugar de redondear cada job al minuto entero, de modo que los pipelines formados por muchos jobs cortos ahorran más. Vea la comparativa completa con los runners alojados por GitHub.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. Descubrimiento de la cadena de suministro: CRACI Package Analytics

Mientras se ejecuta el job, un proxy que entiende de paquetes observa el tráfico hacia las fuentes de paquetes y registra cada dependencia externa que descarga el build, en fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de los presets de descarga de Yocto y OpenEmbedded. La evidencia viaja con las cachés de CI, de modo que los paquetes restaurados desde una caché también quedan registrados.

Esta es la diferencia con otras herramientas de SBOM. Esas herramientas leen el lockfile o el resultado del build y deducen lo que se incluyó. CRACI ve el tráfico, así que también registra las dependencias ocultas que ningún lockfile enumera: el código que descargan los hooks de npm install, los archivos que los scripts de build de Rust obtienen durante el build y las capas de la imagen base de un build de contenedor.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.

Cada job y cada caché reciben un estado de completitud, de Complete a Not recorded, para que sepa hasta qué punto puede confiar en la SBOM resultante. Las SBOM se exportan en CycloneDX o SPDX, con las dependencias transitivas incluidas.

4. Seguridad continua de la cadena de suministro: CRACI Attack Prevention

La misma capa que registra el tráfico también lo controla. Una política de salida decide a qué hosts puede conectarse un job, con denegación o permiso por defecto, presets integrados para las fuentes de software habituales y reglas personalizadas para las suyas. Las políticas se validan antes de que empiece el job y fallan en modo cerrado, y CRACI le alerta ante las infracciones. Una dependencia o herramienta de build comprometida que intente comunicarse con el exterior queda bloqueada en el runner.

Como la política solo permite lo que el build necesita, en lugar de buscar hosts maliciosos conocidos, funciona incluso contra un ataque que nadie ha visto antes. Si un gusano como Shai-Hulud llega primero a su build, el intento de sacar sus secretos queda bloqueado igualmente.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. Respuesta continua en la cadena de suministro: CRACI Vulnerability Analysis

Los paquetes registrados se cotejan con las vulnerabilidades conocidas y las SBOM monitorizadas se reevalúan de forma continua, de modo que una vulnerabilidad divulgada después del lanzamiento también le llega. Las vistas a nivel de organización muestran qué builds y repositorios comparten una dependencia vulnerable, y los equipos de seguridad pueden clasificar cada hallazgo y enviarlo al equipo responsable de la corrección. También puede añadir las SBOM de sus proveedores externos, para que los componentes que compra se monitoricen junto con los que descargan sus propios builds.

Using SBOMs for improved cybersecurity

Cómo una SBOM del build se convierte en monitorización de vulnerabilidades tras la publicación, que es la tarea de la generación de SBOM y el seguimiento de vulnerabilidades de CRACI.

Petteri Pulkkinen y Erika Marttinen en Kubernetes Community Days Helsinki 2026, 22:11 a 23:27 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

6. Trazabilidad de la cadena de suministro: CRACI Digital Inventory

Cada build tiene su SBOM y la traza de red de aquello a lo que se conectó, y la API de CRACI devuelve SBOM, trazas de red y datos de procedencia. Cuando una nueva vulnerabilidad o un paquete comprometido salta a las noticias, puede averiguar desde un solo lugar cuáles de sus builds están afectados.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. Informes de la cadena de suministro: CRACI Compliance Reporting

Las evidencias recopiladas por el camino llegan a quienes las solicitan: clientes, proveedores y autoridades. Las SBOM se exportan en CycloneDX o SPDX, incluidas las vulnerabilidades encontradas en sus componentes, la API devuelve SBOM, trazas de red y datos de procedencia, y CRACI presenta en su nombre las notificaciones de vulnerabilidades del CRA.

El Cyber Resilience Act es la norma más conocida detrás de todo esto, pero no la única. En todos los marcos la exigencia es la misma: saber qué contiene su software y tener un proceso para encontrar y gestionar sus vulnerabilidades.

  • EU Cyber Resilience Act: una SBOM y gestión de vulnerabilidades para los productos con elementos digitales que se venden en la UE, con obligaciones de notificación desde septiembre de 2026.
  • NIS2: seguridad de la cadena de suministro, y gestión y divulgación de vulnerabilidades para las entidades esenciales e importantes.
  • ISO/IEC 27001: no menciona las SBOM, pero sus controles del Anexo A exigen un inventario de activos (5.9), seguridad en la cadena de suministro de las TIC (5.21) y gestión de las vulnerabilidades técnicas (8.8). Las SBOM generadas durante el build y la monitorización continua son evidencias para los tres.
  • US FDA: una SBOM en las solicitudes previas a la comercialización de dispositivos médicos conectados, además de un plan para monitorizar y abordar las vulnerabilidades después del lanzamiento.
  • US Executive Order 14028: SBOM para cada producto y un proceso de divulgación de vulnerabilidades, según las directrices sobre la cadena de suministro de software para los proveedores que venden al Gobierno federal.

CRACI le proporciona las SBOM y la monitorización continua de vulnerabilidades que esperan estos marcos, y las evidencias que respaldan sus afirmaciones de cumplimiento. Cumplir cada marco sigue siendo su proceso; CRACI automatiza la parte de las evidencias.

8. Despliegue: staging y producción

Lo que llega a staging y a producción se ha compilado bajo su política de red, con una SBOM registrada durante el build y monitorizada en busca de nuevas vulnerabilidades después del lanzamiento.

Profundice

Vea CRACI en su propio pipeline

Reserve una demo y repasaremos juntos sus builds, sus SBOM y sus evidencias de cumplimiento.

Reservar una demo