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

Per i team PSIRT

CRACI per i team PSIRT e i responsabili della sicurezza di prodotto

La prima domanda in ogni caso PSIRT è quali dei nostri prodotti e versioni contengono il componente vulnerabile. CRACI risponde partendo da un registro di ciò che ogni build ha effettivamente scaricato, e continua a rispondere man mano che vengono pubblicate nuove CVE.

Aggiornato il

Il problema di un PSIRT manager

Un head of product security risponde di informazioni che il PSIRT non produce da solo. Quando una CVE colpisce una libreria molto diffusa, clienti, dirigenti e, sempre più spesso, autorità di regolamentazione pongono le stesse domande nel giro di poche ore: siamo colpiti, in quali prodotti e versioni, da quando e quando verrà corretta?

Le risposte dipendono dall'inventario, e l'inventario di solito proviene da scanner che leggono lockfile o manifest a posteriori. Elencano dipendenze di sviluppo che non vengono mai distribuite e non vedono i pacchetti che la build ha scaricato in altro modo. Così il PSIRT chiede ai team di engineering di controllare a mano, e la risposta arriva dopo giorni, con riserve.

Il FIRST PSIRT Services Framework definisce un inventario dei componenti di prodotto "essential to quickly identify affected products for inherited vulnerabilities". Da questo inventario parte CRACI. Per il quadro completo del ruolo, veda che cos'è un PSIRT.

Che cosa offre CRACI a un PSIRT

Un inventario registrato dalla build

CRACI esegue le Sue build GitHub Actions sui propri runner e registra i pacchetti effettivamente scaricati da ogni job, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache CI e le dipendenze che nessun lockfile elenca. È un registratore, non uno scanner. Ogni SBOM riporta uno stato di completezza, quindi un record parziale è contrassegnato come tale, e le SBOM si esportano in CycloneDX o SPDX.

Monitoraggio continuo di ciò che è stato distribuito

Le SBOM monitorate vengono rivalutate continuamente man mano che vengono pubblicate nuove vulnerabilità, e i risultati vengono aggregati tra build e repository. Una CVE pubblicata il mese prossimo viene confrontata con le release già distribuite, non solo con la prossima build. Le release malevole note con una CVE pubblicata vengono segnalate come qualsiasi altra vulnerabilità.

Prodotti, versioni e periodi colpiti

La cronologia delle build mostra ogni build passata con la sua SBOM e quali build contenevano una dipendenza vulnerabile, diretta o transitiva, quindi Lei conosce il periodo in cui è stato colpito, entro il Suo periodo di conservazione. La vista inventario mostra esattamente quali versioni del software sono distribuite in quali prodotti. Insieme trasformano "siamo colpiti?" in una semplice consultazione.

Componenti acquistati

Raramente i prodotti sono fatti solo del Suo codice. È possibile aggiungere SBOM dei vendor, così i componenti di terze parti vengono monitorati insieme alle Sue build.

Triage, instradamento e VEX

I team di sicurezza eseguono il triage delle vulnerabilità rilevate e le inviano ai team responsabili della correzione, in linea con il modello PSIRT distribuito in cui la remediation spetta ai team di prodotto. CRACI supporta VEX. Veda VEX per capire come le dichiarazioni di prodotto non colpito facciano risparmiare lavoro a un PSIRT e ai suoi clienti.

Tenere una CVE corretta fuori dalle build successive

I policy gate possono bloccare una build in base ai risultati, anche le build che contengono una CVE specifica. Dopo la chiusura di un caso PSIRT, un gate su quella CVE impedisce alla versione vulnerabile di ricomparire silenziosamente in una release successiva.

Evidenze per audit e clienti

L'API restituisce SBOM, tracce di rete e provenance per ogni build, quindi il record alla base di un advisory o di una risposta di audit è disponibile al di fuori dell'interfaccia. Dove si applica il Cyber Resilience Act dell'UE, CRACI presenta inoltre le notifiche richieste alle autorità per conto del fabbricante; l'obbligo resta a carico del fabbricante. Veda che cos'è il CRA.

Dove si inserisce CRACI nel processo PSIRT

Fase PSIRT Il contributo di CRACI
Preparazione Una SBOM per build, registrata durante l'esecuzione, con uno stato di completezza
Scoperta Rivalutazione continua delle SBOM monitorate, comprese le SBOM dei vendor
Verifica Quali build, versioni e prodotti contengono il componente, e da quando
Remediation Triage verso il team responsabile; policy gate che tengono la CVE fuori dalle build successive
Rilascio e divulgazione Supporto VEX; esportazione SBOM; accesso API al record di build

Le fasi seguono il ciclo di vita della gestione delle vulnerabilità.

Che cosa CRACI non fa

  • Analisi di raggiungibilità. CRACI mostra che un pacchetto vulnerabile era nella build, non se il Suo codice richiama la funzione vulnerabile.
  • Scansione del codice sorgente. SAST e scansione dei secret sono esclusi; molti buoni strumenti li svolgono accanto a CRACI.
  • Sistemi CI diversi da GitHub Actions. Oggi GitHub Actions; altri sistemi CI sono in roadmap.
  • Conformità per Suo conto. CRACI fornisce le evidenze; soddisfare NIS2, il CRA o qualsiasi altro framework resta un processo della Sua organizzazione.

CRACI per i team PSIRT: domande frequenti

CRACI è uno strumento PSIRT?

CRACI copre la parte del lavoro PSIRT che dipende dal sapere che cosa si distribuisce: SBOM in fase di build, il loro monitoraggio continuo, quali build e prodotti contengono un componente vulnerabile e il triage verso il team responsabile. Il Suo canale di divulgazione e il Suo processo di advisory si basano su questo record.

Come fa CRACI a sapere che cosa contiene un prodotto?

Le build vengono eseguite sui runner GitHub Actions di CRACI, e CRACI registra i pacchetti effettivamente scaricati da ogni job, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache CI e le dipendenze che nessun lockfile elenca. È un registratore, non uno scanner. Ogni SBOM riporta uno stato di completezza, quindi Lei sa quando il record è parziale.

CRACI può dirci quali release passate sono state colpite da una CVE?

Sì, entro il Suo periodo di conservazione. La cronologia delle build mostra ogni build passata e la sua SBOM, e quali build contenevano una dipendenza vulnerabile, diretta o transitiva, quindi Lei conosce il periodo in cui è stato colpito. La vista inventario mostra quali versioni del software sono distribuite in quali prodotti.

CRACI copre i componenti che acquistiamo dai fornitori?

Può aggiungere le SBOM dei vendor, così i componenti acquistati vengono monitorati insieme alle Sue build.

CRACI supporta VEX?

Sì. CRACI supporta VEX per registrare in che modo una vulnerabilità nota colpisce il Suo prodotto. Veda VEX per stati e formati, e CSAF per il modo in cui gli advisory li riportano.

Quali sistemi CI supporta CRACI?

Oggi GitHub Actions. Altri sistemi CI sono in roadmap.

Veda l'esposizione dei Suoi prodotti dalla build

Prenoti una demo con le Sue build GitHub Actions: le SBOM registrate da CRACI, le build raggiunte da una CVE e la vista di triage in cui lavorerebbe il Suo PSIRT.

Prenota una demo