Uno dei rischi della catena di fornitura del software è la fuga di segreti. I segreti sono presenti in tutta la catena di fornitura del software; gli sviluppatori e le pipeline CI\CD devono utilizzare segreti per accedere a SCM, pipeline, registri degli artefatti, ambienti cloud e servizi esterni. E quando i segreti sono ovunque, è solo questione di tempo prima che trapelino.
Questo rischio è ben identificato e molti framework della catena di fornitura del software lo risolvono richiedendo la scansione segreta e l'autoscadenza segreta.
Quindi, cosa potrebbe andare storto se tu, come professionista della sicurezza, avessi messo in atto questi guardrail?
Questa settimana, mentre cercavo strumenti di scansione segreti, mi sono imbattuto in una risposta. La risposta è semplice: poiché gli scanner segreti cercano modelli di segreti, quando il formato del segreto cambia, il rilevamento potrebbe non riuscire. E questo è esattamente quello che è successo quando GitHub ha introdotto una nuova funzionalità di sicurezza: il gettoni a grana fine. Questa funzionalità beta è uno dei modi con cui GitHub riduce i rischi di fuga di segreti; limitare le autorizzazioni dei token di accesso personali limita anche i rischi nel caso in cui questi segreti fossero stati compromessi.
Si scopre che il formato dei nuovi token è leggermente diverso, mentre il formato dei vecchi token era qualcosa del tipo:
ghp_123456789012345678901234567890123456
Il nuovo formato token è come:
github_pat_123456789012345678901234567890123456789012345678901234567890…
Sia il prefisso che la lunghezza del segreto sono diversi.
E in effetti, alcuni scanner segreti non riescono a rilevare il nuovo formato;
Per sperimentare, ho creato un repository con un Dockerfile con un segreto e un flusso di lavoro che esegue l'azione Trivy. Ecco come appare il Dockerfile all'inizio dell'esperimento:
Di seguito è riportata un'istantanea di GitHub Secret Scanner, che rileva il segreto appena formattato:
Come possiamo vedere, lo scanner segreto di GitHub rileva il segreto, ma non appare alcun avviso nella sezione Scansione codice.
Per verificare che gli strumenti siano impostati correttamente, ora aggiungerò un classico segreto al Dockerfile (vedi sotto) ed eseguirò nuovamente la scansione. Ora riceviamo un avviso di scansione del codice (solo sul classico segreto!)
Lo scanner di Github, d'altra parte, ora rileva due segreti:
Ho aperto un problema di sicurezza per Trivy; Il team di Trivy ha risposto che questa non è una vulnerabilità né un problema di sicurezza. Ciò che restava da fare era aprire una questione.
Questo esperimento solleva molte preoccupazioni;
- Perché un utente GitHub dovrebbe sospettare che il formato del token verrà modificato a causa di una nuova funzionalità?
- Dato che i segreti dovrebbero apparire come stringhe casuali, perché un utente GitHub dovrebbe preoccuparsi del formato dei segreti?
- GitHub dovrebbe essere responsabile dell'aggiornamento dei propri clienti su tale cambiamento?
- Questo fallimento nel rilevamento dei segreti è una vulnerabilità dei segreti a grana fine di GitHub, una vulnerabilità di Trivy o, come la vede Aqua Security, non è affatto una vulnerabilità?
- Aqua Security, la società dietro Trivy, dovrebbe essere responsabile del suo aggiornamento?
- Dato che Trivy è un progetto open source, fornito così com'è, qualcuno sarebbe responsabile se i segreti fossero trapelati da una pipeline protetta da Trivy? Chi sarebbe? GitHub? Sicurezza dell'acqua? L'utente Trivy?
- Cosa ci insegna questo esperimento sulla fiducia negli strumenti di sicurezza installati per proteggere le catene di fornitura del software?
Lascerò aperte queste domande.
Una cosa è chiara, però; Proteggere la catena di fornitura del software è complicato e abbiamo bisogno di una comunità altamente professionale per riuscire in modo duraturo in questo compito.
Questo post è stato co-autore di Avi Waxman, stagista presso Scribe Security
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
