Scanner di segreti Betterleaks: architettura e chiavi
Il rilevamento di segreti nei repository è cambiato considerevolmente negli ultimi anni. In passato, era sufficiente cercare stringhe sospette o chiavi ad alta entropia nel codice. Oggi la situazione è diversa: repository più grandi, pipeline CI/CD più veloci e, soprattutto, una quantità crescente di codice generato da strumenti automatizzati o modelli di intelligenza artificiale.
Ciò ha una conseguenza pratica: il problema non è più solo trovare segreti, ma distinguere ciò che è realmente pericoloso da ciò che appare tale. Molti team stanno scoprendo che il vero costo di questi scanner non risiede nell'esecuzione dell'analisi, bensì nella revisione di centinaia di falsi positivi.
Architettura di rilevamento: cosa cambia con Betterleaks
Betterleaks si inserisce proprio in questo contesto. Non si propone di reinventare completamente la scansione dei segreti, ma mette in discussione un'ipotesi diffusa: che individuare degli schemi sia sufficiente.
In molti repository moderni non lo è.
Il progetto, sviluppato da Zach Rice e gestito con il supporto di Aikido, propone un approccio leggermente diverso. Invece di concentrarsi esclusivamente sull'individuazione delle corrispondenze, cerca di verificare se il risultato ha senso prima di segnalarlo come un allarme.
Potrebbe sembrare un dettaglio di poco conto, ma cambia significativamente le dinamiche all'interno di team numerosi. Quando un sistema di scansione genera troppi avvisi irrilevanti, la reazione naturale del team è quella di ignorarli. E nel campo della sicurezza, un avviso ignorato può essere peggio di nessun avviso.
Per affrontare questo problema, Betterleaks introduce due interessanti elementi tecnici: la validazione tramite CEL (Common Expression Language) e una metrica chiamata "Token Efficiency", basata sulla tokenizzazione BPE.
L'idea di base è che non tutto ciò che appare segreto lo è davvero. Alcune stringhe ad alta entropia sono semplicemente hash, identificatori o frammenti generati automaticamente. L'obiettivo del sistema è ridurre questo rumore.
La documentazione del progetto menziona un confronto in cui la tokenizzazione BPE raggiunge un tasso di recall del 98,6% rispetto al 70,4% ottenuto utilizzando l'entropia nel dataset CredData. Come per qualsiasi benchmark, questi numeri sono indicativi. Servono come punto di riferimento, ma non sostituiscono i test su repository reali.
Fonte: GitHub
Componenti che fanno la differenza
Esaminando le caratteristiche del progetto, emerge una chiara direzione: facilitare l'implementazione in ambienti reali senza aggiungere eccessiva complessità tecnica.
Tra gli elementi più importanti figurano:
- Validazione basata su regole tramite CEL (Common Expression Language)
- Scansione dell'efficienza dei token basata sulla tokenizzazione BPE anziché sull'entropia, con un recall del 98,6% rispetto al 70,4% con l'entropia sul dataset CredData.
- Implementazione in puro Go (senza dipendenza da CGO o Hyperscan)
- Gestione automatica di segreti con doppia/tripla codifica
- Set di regole ampliato per un maggior numero di fornitori
- Scansione Git parallela per un'analisi più rapida del repository
Sebbene questo elenco possa sembrare solo una serie di miglioramenti tecnici, ciò che è interessante è il modo in cui influenzano l'utilizzo quotidiano.
Ad esempio, un'implementazione completa in Go senza dipendenze native semplifica notevolmente l'integrazione nelle pipeline CI/CD. In molti team, piccoli dettagli come questo determinano se uno strumento viene effettivamente utilizzato o se finisce dimenticato in un repository.
La tokenizzazione BPE introduce anche un approccio diverso. Invece di limitarsi a misurare la casualità di una catena, analizza i modelli dei token che riflettono più fedelmente la struttura effettiva delle credenziali moderne.
Cosa succede quando lo scanner rileva qualcosa?
Quando Betterleaks individua un potenziale segreto, il processo non si conclude lì.
Innanzitutto, il contesto viene valutato utilizzando le regole definite in CEL. Ciò consente di aggiungere ulteriori condizioni: ad esempio, verificare se il formato corrisponde al fornitore previsto o scartare i modelli che compaiono frequentemente negli esempi o nei dati fittizi.
Questo passaggio può sembrare banale, ma ha un impatto pratico significativo. I falsi positivi non solo fanno perdere tempo, ma riducono anche la fiducia del team nel sistema di allerta.
Un altro aspetto interessante è la gestione automatica dei segreti codificati più volte. In alcuni repository, le credenziali appaiono trasformate utilizzando base64 o altri schemi di codifica, il che ne complica l'individuazione.
Ciò nonostante, è bene ricordare un aspetto che a volte viene trascurato: nessuno scanner può sostituire completamente la revisione umana. Individuare un segreto è solo l'inizio; decidere cosa farne (revocare, ruotare, ignorare o indagare) rimane una decisione contestuale.
Governance e approccio incentrato sull'uomo/IA
Betterleaks è pubblicato con licenza MIT e include contributi esterni da organizzazioni come Royal Bank of Canada, Red Hat e Amazon.
Il progetto cerca inoltre di adattarsi a una realtà sempre più visibile nei repository moderni: la commistione di codice scritto dagli sviluppatori e codice generato da strumenti automatizzati.
In questo contesto, lo strumento mira a funzionare bene sia nei flussi di lavoro gestiti dall'uomo che nei sistemi automatizzati che esaminano interi repository. Ciò si allinea con il crescente utilizzo di automazione e strumenti che analizzano il codice o generano revisioni automatiche.
La roadmap include anche idee interessanti: integrazione con fonti di dati diverse da GitSupporto tramite modelli linguistici per la classificazione dei risultati e meccanismi di revoca automatica tramite API del fornitore.
Questo apre un interessante dibattito. Automatizzare la revoca delle credenziali può ridurre i tempi di risposta a un incidente, ma significa anche fare affidamento sull'accuratezza del sistema di classificazione.
Se la revoca automatica non va a buon fine o viene attivata per errore, l'impatto operativo può essere considerevole.
Implicazioni pratiche e limitazioni
Dal punto di vista operativo, Betterleaks è interessante per i team che desiderano ridurre i falsi positivi e semplificare le implementazioni.
Ma è anche importante tenere a mente alcuni limiti:
- Le metriche di recall dipendono dal set di dati utilizzato e possono variare considerevolmente tra i diversi repository.
- L'automazione di azioni come la revoca delle chiavi richiede controlli aggiuntivi e registri di controllo.
- Gli scanner segreti rappresentano solo un livello di difesa all'interno di una strategia più ampia.
In molti casi, la decisione di adottare uno strumento di questo tipo non dipende tanto dalla sua accuratezza teorica quanto da un fattore più semplice: la sua capacità di integrarsi bene nel flusso di lavoro del team.
Uno scanner estremamente preciso che genera troppa resistenza viene solitamente scartato. Uno scanner ragionevolmente preciso e facile da integrare viene invece generalmente mantenuto.
In tal senso, Betterleaks cerca di trovare un equilibrio. Non promette di eliminare tutti i falsi positivi o di sostituire i processi di sicurezza esistenti, ma mira a ridurre il rumore e a facilitare l'integrazione nei moderni flussi di lavoro.
Il progetto è disponibile su GitHub. e si presenta come un'evoluzione dell'approccio utilizzato da Gitleaks, con l'intento di adattarsi ai repository in cui l'automazione, gli agenti di analisi e il codice generato da modelli linguistici sono parte integrante del flusso di sviluppo.
