124% di CVE segnalate in più al giorno nel 2026 rispetto all'anno scorso.

Piattaforma

Come funziona CRACI

CRACI esegue le Sue build GitHub Actions e registra ciò che ognuna scarica. Tutto il resto, dal monitoraggio delle vulnerabilità alle evidenze CRA, si basa su questo registro.

Aggiornato il

Panoramica della piattaforma CRACI. Il codice sorgente su GitHub passa attraverso GitHub Actions fino al CRACI Secure Build Service. La build alimenta CRACI Package Analytics, poi Vulnerability Analysis (che riceve input anche da fornitori terzi), Digital Inventory e Compliance Reporting, che riferisce a terze parti come clienti, fornitori ed ENISA. La build alimenta anche CRACI Attack Prevention. Attack Prevention e Digital Inventory portano entrambi al deployment in staging e in produzione.
La piattaforma CRACI, da sinistra a destra. Apri lo schema a grandezza intera.

In sintesi

La maggior parte degli strumenti di sicurezza esamina il codice o i manifest a posteriori e deduce che cosa una build conteneva probabilmente. CRACI è il runner della build, quindi vede ciò che la build ha effettivamente scaricato, nel momento in cui l'ha scaricato. Questo registro è l'input di tutto ciò che compare nello schema: analisi dei pacchetti, prevenzione degli attacchi, analisi delle vulnerabilità, tracciabilità e reportistica di conformità.

Lei mantiene GitHub e GitHub Actions. La modifica è una riga in ogni 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.

Passo dopo passo

1. Codice sorgente e CI/CD: GitHub e GitHub Actions

Il Suo codice resta su GitHub. Collega la Sua organizzazione installando la GitHub App di CRACI, su tutti i repository o solo su quelli che sceglie. I workflow continuano a essere eseguiti da GitHub Actions e le loro esecuzioni compaiono ancora in GitHub. Oggi l'integrazione CI supportata è GitHub Actions; il supporto ad altri sistemi CI/CD è in roadmap.

2. Build: CRACI Secure Build Service

I job vengono eseguiti sui runner CRACI, in macchine virtuali isolate. I runner vanno da 1 a 32 unità di calcolo (1 vCPU e 3 GB di RAM ciascuna), su x86-64 e ARM64 nativi, con un'immagine Ubuntu compatibile con GitHub o con le immagini leggere di CRACI. L'utilizzo viene misurato al secondo.

Su CRACI le build sono circa due volte più veloci che sui runner ospitati standard di GitHub. E ogni minuto costa meno: un runner Linux standard da 2 vCPU costa $0.004 al minuto, contro i $0.006 di GitHub (circa il 33% in meno). Nel complesso, una build che su GitHub richiede 10 minuti su CRACI termina in circa 5 e costa circa il 67% in meno. Inoltre CRACI fattura al secondo invece di arrotondare per eccesso ogni job al minuto intero, quindi le pipeline composte da molti job brevi risparmiano di più. Veda il confronto completo con i runner ospitati da 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. Individuazione della supply chain: CRACI Package Analytics

Mentre il job è in esecuzione, un proxy che riconosce i pacchetti osserva il traffico verso le sorgenti dei pacchetti e registra ogni dipendenza esterna scaricata dalla build, da npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download di Yocto e OpenEmbedded. Le evidenze viaggiano con le cache CI, quindi anche i pacchetti ripristinati da una cache vengono conteggiati.

È questa la differenza rispetto agli altri strumenti SBOM. Leggono il lockfile o l'output della build e ricavano che cosa vi è entrato. CRACI vede il traffico, quindi registra anche le dipendenze nascoste che nessun lockfile elenca: il codice scaricato dagli hook di npm install, i file che gli script di build Rust recuperano in fase di build e i layer dell'immagine base di una build di container.

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.

Ogni job e ogni cache riceve uno stato di completezza, da Complete a Not recorded, così Lei sa quanto può fidarsi della SBOM prodotta. Le SBOM si esportano in CycloneDX o SPDX, dipendenze transitive incluse.

4. Sicurezza continua della supply chain: CRACI Attack Prevention

Lo stesso livello che registra il traffico lo controlla anche. Una policy di egress stabilisce quali host un job può raggiungere, con negazione o autorizzazione predefinita, preset integrati per le sorgenti software più comuni e regole personalizzate per le Sue. Le policy vengono convalidate prima dell'avvio del job e operano in modalità fail closed, e CRACI La avvisa in caso di violazioni. Una dipendenza o uno strumento di build compromesso che cerca di contattare il proprio server viene fermato sul runner.

Poiché la policy consente solo ciò di cui la build ha bisogno, invece di cercare host notoriamente malevoli, funziona anche contro un attacco mai visto prima. Se un worm come Shai-Hulud raggiunge per primo la Sua build, il suo tentativo di esfiltrare i Suoi secret viene bloccato comunque.

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. Risposta continua sulla supply chain: CRACI Vulnerability Analysis

I pacchetti registrati vengono confrontati con le vulnerabilità note e le SBOM monitorate vengono rivalutate di continuo, così anche una vulnerabilità resa nota dopo il rilascio Le arriva. Le viste a livello di organizzazione mostrano quali build e quali repository condividono una dipendenza vulnerabile, e i team di sicurezza possono esaminare ogni risultato e inoltrarlo al team responsabile della correzione. Può anche aggiungere le SBOM dei Suoi fornitori terzi, così i componenti che acquista vengono monitorati insieme a quelli scaricati dalle Sue build.

Using SBOMs for improved cybersecurity

Come una SBOM di build diventa monitoraggio delle vulnerabilità dopo il rilascio, che è il compito della generazione di SBOM e del tracciamento delle vulnerabilità di CRACI.

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

6. Tracciabilità della supply chain: CRACI Digital Inventory

Ogni build ha la propria SBOM e la traccia di rete delle connessioni effettuate, e l'API di CRACI restituisce SBOM, tracce di rete e provenance. Quando una nuova vulnerabilità o un pacchetto compromesso fa notizia, Lei può stabilire da un unico punto quali delle Sue build sono colpite.

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. Reportistica sulla supply chain: CRACI Compliance Reporting

Le evidenze raccolte lungo il percorso arrivano a chi le richiede: clienti, fornitori e autorità. Le SBOM si esportano in CycloneDX o SPDX, comprese le vulnerabilità rilevate nei loro componenti, l'API restituisce SBOM, tracce di rete e provenance, e CRACI invia per Suo conto le notifiche di vulnerabilità previste dal CRA.

Il Cyber Resilience Act è la norma più nota alla base di tutto questo, ma non l'unica. In tutti i framework la richiesta è la stessa: sapere che cosa c'è nel proprio software e avere un processo per individuarne e gestirne le vulnerabilità.

  • Cyber Resilience Act dell'UE: una SBOM e la gestione delle vulnerabilità per i prodotti con elementi digitali venduti nell'UE, con obblighi di segnalazione da settembre 2026.
  • NIS2: sicurezza della supply chain, gestione e divulgazione delle vulnerabilità per i soggetti essenziali e importanti.
  • ISO/IEC 27001: non cita le SBOM, ma i controlli dell'Annex A richiedono un inventario degli asset (5.9), la sicurezza nella supply chain ICT (5.21) e la gestione delle vulnerabilità tecniche (8.8). Le SBOM in fase di build e il monitoraggio continuo sono evidenze per tutti e tre.
  • FDA (USA): una SBOM nelle domande di autorizzazione pre-commercializzazione per i dispositivi medici connessi, oltre a un piano per monitorare e gestire le vulnerabilità dopo il rilascio.
  • Executive Order 14028 (USA): SBOM per ogni prodotto e un processo di divulgazione delle vulnerabilità, nelle linee guida sulla software supply chain per i fornitori che vendono al governo federale.

CRACI Le fornisce le SBOM e il monitoraggio continuo delle vulnerabilità che questi framework si aspettano, oltre alle evidenze a sostegno delle Sue dichiarazioni di conformità. Rispettare ciascun framework resta un Suo processo; CRACI ne rende automatica la parte relativa alle evidenze.

8. Deployment: staging e produzione

Ciò che arriva in staging e in produzione è stato compilato secondo la Sua policy di rete, con una SBOM registrata durante la build e monitorata alla ricerca di nuove vulnerabilità dopo il rilascio.

Per approfondire

Veda CRACI sulla Sua pipeline

Prenoti una demo: esamineremo insieme le Sue build, le Sue SBOM e le Sue evidenze di conformità.

Prenota una demo