Funzionalità
Policy gate: fermare le vulnerabilità prima della produzione
Uno scanner Le segnala una vulnerabilità. Un policy gate ferma la build che la contiene. I gate di CRACI decidono in base alla registrazione di ciò che ogni build ha effettivamente scaricato, così un pacchetto vulnerabile non arriva in produzione solo perché nessuno ha letto l'avviso in tempo.
Aggiornato il
Perché gli avvisi non bastano
La maggior parte degli strumenti di sicurezza segnala a posteriori. Un risultato finisce in una dashboard, qualcuno ne esegue il triage, un ticket arriva al team responsabile, e nel frattempo la release va avanti. Se il risultato è sfuggito o la scansione non ha mai visto il pacchetto, la vulnerabilità è in produzione prima che qualcuno decida qualcosa.
I policy gate possono anche fermare una build in tempo reale, prima che la release vada avanti.
Che cosa può fermare un gate
| Regola | Che cosa succede |
|---|---|
| Risultati nella build | Una build con risultati che la Sua policy esclude viene bloccata. |
| Una CVE specifica | Una volta che il Suo team ha deciso che una CVE non deve essere distribuita, le build che la contengono vengono bloccate. |
| Una release malevola nota | Una release malevola con una CVE pubblicata, come xz, viene segnalata e può essere bloccata allo stesso modo. |
| Una licenza | Le regole di policy sulle licenze possono bloccare una build che introduce una licenza da Lei esclusa. |
Un gate vale quanto ciò che vede
Un gate basato sulla scansione di un lockfile può bloccare solo ciò che il lockfile elenca. CRACI vede il traffico in ingresso in ogni build, quindi i suoi gate lavorano su ciò che il job ha davvero scaricato:
- Dipendenze transitive a ogni profondità. Veda dipendenze transitive.
- Dipendenze nascoste, come il codice scaricato dagli script di installazione, gli script di build di Rust che scaricano file in fase di build e l'immagine base di una build di container.
- Pacchetti ripristinati da una cache CI, che vengono registrati e contrassegnati come provenienti dalla cache.
Ogni componente in una SBOM di CRACI era nella build, quindi un gate non lavora mai su un pacchetto solo dedotto. Per le motivazioni, veda le SBOM in fase di build.
Gate e policy di egress svolgono compiti diversi
| Rischio | Che cosa lo ferma |
|---|---|
| Una dipendenza con una CVE nota da Lei esclusa | Policy gate |
| Una licenza da Lei esclusa | Policy gate |
| Una connessione a un host di cui la build non ha bisogno | Policy di egress, impostata su deny predefinito |
| Un nuovo pacchetto malevolo ancora senza advisory | Non viene segnalato finché non esiste un advisory. Una policy di egress impostata su deny predefinito gli impedisce comunque di inviare i Suoi secret a un host di cui la build non ha bisogno. |
Quando emerge una nuova CVE
- CRACI rivaluta le SBOM monitorate e segnala ciò che è colpito.
- Il Suo team di sicurezza ne esegue il triage e la invia al team responsabile della correzione.
- La cronologia delle build mostra quali build la contenevano, e quindi per quanto tempo Lei è stato esposto.
- Il team responsabile distribuisce la correzione, e un policy gate tiene la CVE fuori dalle build successive.
La correzione resta compito Suo. Il gate fa in modo che il problema resti risolto. Veda il monitoraggio delle vulnerabilità.
Che cosa non fanno i gate
- Nessuna analisi di raggiungibilità. Un gate si basa sulla presenza di un pacchetto nella build, non sul fatto che il Suo codice chiami la funzione vulnerabile.
- Nessun rilevamento di malware. Il gate è guidato dagli advisory, quindi non intercetta un pacchetto malevolo appena comparso.
- Nessuna scansione del codice. SAST e scansione dei secret sono volutamente fuori ambito, e molti ottimi strumenti funzionano accanto a CRACI.
Policy gate: domande frequenti
Che cos'è un policy gate?
Una regola che ferma una build quando viola la Sua policy. Invece di segnalare un problema di cui qualcuno si occuperà più tardi, il gate impedisce alla build di proseguire.
In che cosa un policy gate è diverso da un avviso di uno scanner?
Un avviso dipende da qualcuno che intervenga in tempo. Un gate agisce da solo. I gate di CRACI lavorano inoltre su una registrazione di ciò che la build ha scaricato, quindi possono intercettare pacchetti che la scansione di un lockfile non vedrebbe mai.
Posso bloccare una CVE specifica?
Sì. Un policy gate può bloccare le build che contengono una CVE specifica, così una vulnerabilità su cui il Suo team ha deciso non ritorna in una build successiva.
Un gate può bloccare una licenza?
Sì. Ogni pacchetto registrato porta con sé la propria licenza dichiarata, e le regole di policy sulle licenze possono bloccare una build in base a una licenza.
Un gate ferma i nuovi malware?
Non da solo. Una release malevola nota con una CVE pubblicata viene segnalata come qualsiasi altra vulnerabilità, e un gate può bloccare le build che la contengono. Un nuovo pacchetto malevolo non viene segnalato finché non esiste un advisory. In quella finestra, è una policy di egress impostata su deny predefinito a limitare i danni.
Quali sistemi CI funzionano con i policy gate?
GitHub Actions, sui runner CRACI. Gli altri sistemi CI sono in roadmap.
Veda un gate fermare una build reale
Prenoti una demo e veda un policy gate bloccare una build che contiene un pacchetto vulnerabile.
Prenota una demo