![\"Betterleaks,](\"https:\/\/mastertrend.info\/wp-content\/uploads\/2025\/11\/GreyNoise-lanza-un-escaner-gratuito-para-comprobar-si-formas-parte.jpg\" "\\"\\"")
<\/p>\nIl rilevamento di segreti nei repository \u00e8 cambiato considerevolmente negli ultimi anni. In passato, era sufficiente cercare stringhe sospette o chiavi ad alta entropia nel codice. Oggi la situazione \u00e8 diversa: repository pi\u00f9 grandi, pipeline CI\/CD pi\u00f9 veloci e, soprattutto, una quantit\u00e0 crescente di codice generato da strumenti automatizzati o modelli di intelligenza artificiale.<\/p>\n
Ci\u00f2 ha una conseguenza pratica: il problema non \u00e8 pi\u00f9 solo trovare segreti, ma distinguere ci\u00f2 che \u00e8 realmente pericoloso da ci\u00f2 che appare tale. Molti team stanno scoprendo che il vero costo di questi scanner non risiede nell'esecuzione dell'analisi, bens\u00ec nella revisione di centinaia di falsi positivi.<\/p>\n
<\/p>\n
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.<\/p>\n
In molti repository moderni non lo \u00e8.<\/p>\n
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.<\/p>\n
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 \u00e8 quella di ignorarli. E nel campo della sicurezza, un avviso ignorato pu\u00f2 essere peggio di nessun avviso.<\/p>\n
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.<\/p>\n
L'idea di base \u00e8 che non tutto ci\u00f2 che appare segreto lo \u00e8 davvero. Alcune stringhe ad alta entropia sono semplicemente hash, identificatori o frammenti generati automaticamente. L'obiettivo del sistema \u00e8 ridurre questo rumore.<\/p>\n
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.<\/p>\n
![\"scansione](\"https:\/\/mastertrend.info\/wp-content\/uploads\/2026\/03\/Betterleaks-un-nuevo-escaner-de-secretos-de-codigo-abierto-para.jpg\" "\\"\\"")
Esaminando le caratteristiche del progetto, emerge una chiara direzione: facilitare l'implementazione in ambienti reali senza aggiungere eccessiva complessit\u00e0 tecnica.<\/p>\n
Tra gli elementi pi\u00f9 importanti figurano:<\/p>\n
Sebbene questo elenco possa sembrare solo una serie di miglioramenti tecnici, ci\u00f2 che \u00e8 interessante \u00e8 il modo in cui influenzano l'utilizzo quotidiano.<\/p>\n
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.<\/p>\n
La tokenizzazione BPE introduce anche un approccio diverso. Invece di limitarsi a misurare la casualit\u00e0 di una catena, analizza i modelli dei token che riflettono pi\u00f9 fedelmente la struttura effettiva delle credenziali moderne.<\/p>\n
Quando Betterleaks individua un potenziale segreto, il processo non si conclude l\u00ec.<\/p>\n
Innanzitutto, il contesto viene valutato utilizzando le regole definite in CEL. Ci\u00f2 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.<\/p>\n
Questo passaggio pu\u00f2 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.<\/p>\n
Un altro aspetto interessante \u00e8 la gestione automatica dei segreti codificati pi\u00f9 volte. In alcuni repository, le credenziali appaiono trasformate utilizzando base64 o altri schemi di codifica, il che ne complica l'individuazione.<\/p>\n
Ci\u00f2 nonostante, \u00e8 bene ricordare un aspetto che a volte viene trascurato: nessuno scanner pu\u00f2 sostituire completamente la revisione umana. Individuare un segreto \u00e8 solo l'inizio; decidere cosa farne (revocare, ruotare, ignorare o indagare) rimane una decisione contestuale.<\/p>\n
Betterleaks \u00e8 pubblicato con licenza MIT e include contributi esterni da organizzazioni come Royal Bank of Canada, Red Hat e Amazon.<\/p>\n
Il progetto cerca inoltre di adattarsi a una realt\u00e0 sempre pi\u00f9 visibile nei repository moderni: la commistione di codice scritto dagli sviluppatori e codice generato da strumenti automatizzati.<\/p>\n
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\u00f2 si allinea con il crescente utilizzo di automazione e strumenti<\/a> che analizzano il codice o generano revisioni automatiche.<\/p>\n