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?
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