Secret scanning open source nel 2026: sei scanner alla prova sullo stesso repository

Quali scanner di segreti open source sono ancora mantenuti nel 2026?

Betterleaks, Gitleaks, TruffleHog, Kingfisher, Titus e secretlint hanno pubblicato ciascuno una release nel 2026, sugli undici scanner di segreti open source che abbiamo controllato il 29 ottobre 2026. Nosey Parker è archiviato, mentre detect-secrets e git-secrets sono fermi da più di due anni senza una release. La tabella riporta quello che dicevano quel giorno l'API di GitHub e il README di ciascun progetto: la licenza, l'ultima release, se lo strumento sa testare un segreto presso il suo provider e se scrive SARIF. Le stelle misurano l'attenzione, non la manutenzione, quindi le abbiamo lasciate fuori.

Due righe ribaltano il consiglio che si legge di solito. Gitleaks funziona ancora e il suo repository riceve ancora commit, ma dal 21 maggio 2026 il suo README lo definisce «feature complete» e avverte che le prossime release saranno «solo patch di sicurezza». Il suo autore originale è passato a Betterleaks, un nuovo progetto MIT creato a febbraio 2026 da chi ha fatto Gitleaks, con uno sviluppo sostenuto da Aikido Security. Quanto a Nosey Parker, ancora citato in tanti elenchi, Praetorian lo ha archiviato e sostituito con Titus, uno scanner scritto in Go le cui 487 regole sono riprese da Nosey Parker e da Kingfisher.

Conta anche chi c'è dietro ogni strumento. Kingfisher è di MongoDB, detect-secrets di Yelp, git-secrets viene da AWS Labs e Talisman da Thoughtworks. TruffleHog è lo scanner open source di Truffle Security, con licenza AGPL-3.0 dalla versione 3.0. Whispers di Skyscanner, che alcuni elenchi riportano ancora, è archiviato, e la sua ultima release è la 1.5.3 di agosto 2021.

Cosa ha trovato ogni scanner in un repository pieno di segreti finti?

Nel nostro test del 29 ottobre 2026, sei scanner di segreti open source hanno analizzato lo stesso repository, in cui avevamo piazzato 12 credenziali finte: Betterleaks ne ha trovate 12, Titus 11, Gitleaks e Kingfisher 10, TruffleHog e detect-secrets 9. Sono sfuggite password e un segreto di firma JWT senza prefisso di un provider, una chiave presente solo nella history di git e, a Titus, una chiave Stripe live. Titus e detect-secrets hanno segnalato un'esca ciascuno.

Il 29 ottobre 2026 abbiamo costruito un piccolo repository che sembra l'API di un e-commerce, con TypeScript, Python, un file di settings Django, un file Docker Compose e uno script di deploy in shell, distribuito su tre commit. Abbiamo piazzato 12 credenziali finte nei punti in cui di solito finiscono:

• una coppia di chiavi di accesso AWS in un file di configurazione TypeScript;
• un personal access token GitHub in un header curl;
• una chiave Stripe live nel .env;
• il token di un bot Slack in un file YAML;
• una chiave OpenAI e una chiave Anthropic nelle chiamate agli SDK;
• una chiave API Google in un tag script HTML;
• una password dentro una stringa di connessione Postgres;
• un segreto di firma JWT in Node.js;
• la password del database di Django;
• una chiave privata RSA;
• una chiave SendGrid in un file .env.production cancellato da un commit successivo.

Ogni valore era casuale e ricalcava il formato del provider, e nessuno era una chiave vera. Due esche stavano nel README: la chiave di esempio documentata da AWS, AKIAIOSFODNN7EXAMPLE, e un placeholder Stripe fatto di x. Ogni strumento è partito con le sue regole di default, in modalità history di git dove esiste, su un Mac, con le versioni che Homebrew distribuiva quel giorno. Le verifiche live erano disattivate, perché una chiave finta non si può verificare:

gitleaks git . --report-format json --report-path gitleaks.json
betterleaks git . --report-format json --report-path betterleaks.json
trufflehog git file://. --no-verification --json > trufflehog.jsonl
kingfisher scan . --no-validate --format json --output kingfisher.json
titus scan --git . --format json --output :memory: > titus.json
detect-secrets scan --all-files > detect-secrets.json

Tutti e sei hanno trovato la chiave AWS, il token GitHub, il token Slack, la chiave Anthropic e la chiave privata. I buchi più grandi li hanno aperti i segreti senza prefisso: Gitleaks, Kingfisher e TruffleHog si sono persi la password del database Django, e Kingfisher e TruffleHog anche il segreto di firma JWT. Nemmeno le chiavi dei provider sono passate tutte: TruffleHog e detect-secrets non hanno visto la chiave API Google, detect-secrets la chiave OpenAI e Titus la chiave Stripe live. Un valore assegnato a JWT_SECRET è una stringa casuale senza un formato da riconoscere, quindi lo intercettano solo le regole che guardano il nome della variabile o l'entropia della stringa.

La chiave SendGrid esisteva solo in un commit che il commit successivo aveva cancellato. Tutti gli strumenti che leggono la history di git l'hanno trovata. detect-secrets no, e il suo README spiega perché: evita di «scavare in tutta la history di git» e analizza i file attuali, con una baseline delle segnalazioni già note.

Le due esche hanno ingannato strumenti diversi. Gitleaks e Betterleaks ignorano le chiavi AWS che finiscono con EXAMPLE, perché la loro regola AWS di default prevede questa eccezione, quindi la chiave della documentazione è passata senza allarmi; detect-secrets invece l'ha segnalata. Titus ha preso il placeholder fatto di x per una chiave Stripe e si è perso la vera chiave Stripe nel .env. Abbiamo provato anche Nosey Parker 0.24.0, che ha fatto esattamente lo stesso, e il risultato torna con regole riprese da quelle di Nosey Parker.

Le segnalazioni sono più numerose delle credenziali. Titus ha generato 16 segnalazioni per 11 credenziali e detect-secrets 15 per 9, perché più regole hanno colpito lo stesso valore: un token GitHub preso sia come token sia come header curl, una chiave OpenAI ripresa una seconda volta come chiave generica. Ogni duplicato è una riga in più da smistare.

TruffleHog vs Gitleaks vs Betterleaks: quale conviene usare?

Per una configurazione nuova parti da Betterleaks, tieni Gitleaks se sta già nei tuoi hook e ti basta che continui a funzionare, e aggiungi TruffleHog o Kingfisher quando sapere se una chiave è attiva conta più che intercettare ogni password. Gli strumenti si distinguono per le regole, per la manutenzione e per quello che fanno dopo un match.

Gitleaks (MIT, v8.30.1) fa ancora il suo lavoro: nel nostro test non ha dato falsi allarmi e si è perso due password. Non riceverà nuove regole. Abbandonarlo costa poco, perché Betterleaks legge un file .gitleaks.toml e rispetta i commenti gitleaks:allow.

Betterleaks (MIT) ha trovato tutto, nel nostro test. La 1.9.0 è la release stabile e la validazione si attiva con un flag, --validation. La versione 2 è in release candidate, e la sua guida alla migrazione dice che i reporter CSV, JUnit, SARIF e template «sono stati rimossi». Se la tua pipeline legge SARIF, per ora resta sulla 1.x.

TruffleHog (AGPL-3.0) dichiara oltre 800 tipi di segreti e oltre 700 detector che testano le credenziali sulle API dei rispettivi servizi, e lancia questi test di default. Per AWS, il README dice che chiama GetCallerIdentity. --results=verified tiene solo i segreti confermati come attivi, e nel nostro test, con la verifica disattivata, è stato anche quello che ha generato meno segnalazioni. Si è perso la chiave API Google, il segreto di firma JWT e la password di Django. Ha licenza AGPL-3.0: fai leggere la licenza al tuo ufficio legale prima di integrarlo in un prodotto o di ridistribuirlo.

Kingfisher (Apache-2.0, Rust) valida le segnalazioni di default e ne sa revocare alcune. Dalla versione 2.0.0 del 23 agosto 2026 le sue regole vengono dal catalogo di Betterleaks: 462 delle sue 488 regole, più 26 da Veles di Google. Abbiamo testato la 2.14.0; la 2.15.0 era uscita il giorno prima.

Titus (Apache-2.0, Go) è dove approda chi usava Nosey Parker. Valida con --validate e scrive SARIF.

Uno scanner di segreti deve verificare se una chiave è ancora attiva?

Sì, per il triage, a patto che sia tu a decidere dove gira la verifica. Una verifica live manda la credenziale trovata all'API del suo provider e ti dice quali segnalazioni sono un incidente e quali sono chiavi morte. TruffleHog e Kingfisher la fanno di default, Betterleaks e Titus solo con un flag, Gitleaks mai.

La verifica è una richiesta vera con il segreto vero. Lanciala dove la tua policy di rete consente le chiamate verso quei provider, e tieni i risultati fuori dai log pubblici della CI. Anche il secret scanning di GitHub propone la stessa idea, con i «validity checks» da attivare su richiesta.

Non verificato non vuol dire innocuo. La password di un database che sta sulla tua rete privata non si può testare da un runner CI fuori da quella rete, quindi uno strumento che verifica la riporta come non verificata, e un filtro sui soli risultati verificati la fa sparire.

Dove far girare il secret scanning: pre-commit, CI o dentro l'agente?

In tre punti: un hook pre-commit su ogni portatile, una scansione in CI a ogni push che lo sviluppatore non può saltare, e una scansione completa della history quando adotti lo strumento. L'hook pre-commit da solo non basta, perché git commit --no-verify scavalca gli hook pre-commit e commit-msg, come scrive la documentazione di git.

Su GitHub, la push protection blocca un push che contiene un segreto rilevato. Il secret scanning gira gratis sui repository pubblici; sui repository privati e interni di un'organizzazione richiede GitHub Secret Protection su GitHub Team o GitHub Enterprise Cloud, fatturato per committer attivo.

Gli agenti di coding aggiungono un passaggio prima del commit. Claude Code, Cursor o Codex possono leggere un file .env quando niente glielo vieta, come abbiamo mostrato spiegando cosa Claude Code invia ad Anthropic e come tenere il .env fuori portata, e un valore che l'agente ha letto può finire in un file che scrive.

È il passaggio su cui lavora CybeDefend: le guardie di VibeDefend rifiutano la lettura del .env da parte dell'agente in Claude Code, Cursor e Codex e lo rimandano alla variabile d'ambiente, mentre la scansione del diff controlla i file modificati dall'agente alla ricerca di segreti, problemi SAST e IaC prima che vengano committati. Come funziona VibeDefend mostra entrambe le cose.

La pull request resta l'ultimo cancello, e i controlli di sicurezza da fare sulla pull request di un agente AI comprendono una passata sui segreti.

Come si uniscono i risultati degli scanner di segreti con quelli degli altri scanner?

Fai scrivere a ogni scanner un file SARIF 2.1.0, il formato che leggono le piattaforme di hosting del codice e gli strumenti di gestione delle vulnerabilità, poi unisci i file. Cinque dei sei strumenti testati lo scrivono, e ogni comando qui sotto ha prodotto un SARIF 2.1.0 valido sul nostro repository di test. Due trappole: Betterleaks v2 elimina il suo reporter SARIF, e l'help di Kingfisher definisce ancora sperimentale il suo output SARIF.

gitleaks git . --report-format sarif --report-path gitleaks.sarif
betterleaks git . --report-format sarif --report-path betterleaks.sarif   # 1.x only
trufflehog git file://. --sarif > trufflehog.sarif
kingfisher scan . --format sarif --output kingfisher.sarif
titus scan --git . --format sarif --output :memory: > titus.sarif

Scansioni pre-commit e CIUn file SARIF ciascunoUnione e deduplicaTriage e storico

Un file unito non è ancora una lista smistata. La stessa chiave torna da due strumenti con due nomi di regola diversi, un falso positivo che avevi scartato ricompare alla scansione successiva, e niente conserva la traccia che un auditor ti chiede. Il problema dello smistamento è lo stesso che descriviamo in perché gran parte delle segnalazioni SAST è rumore.

CybeDefend Open Source è pensato per questo passaggio. Fa girare gli scanner che scegli tu, qualsiasi strumento che scriva SARIF, e mette quello che trovano in un'unica coda deduplicata, gratis e sui tuoi server. Uscirà a breve, e la lista d'attesa è aperta.

Quali scanner di segreti gratuiti non sono del tutto open source o locali?

Il secret scanning di GitHub e ggshield di GitGuardian si usano gratis per iniziare, ma nessuno dei due gira interamente sulla tua macchina con una licenza open source. GitHub scansiona gratis i repository pubblici e per quelli privati richiede un piano Secret Protection a pagamento. La CLI di ggshield è MIT, ma la scansione passa dall'API di GitGuardian e serve un account.

Lo scanning di GitHub è una funzione ospitata: legge tutta la history di un repository su GitHub, su ogni branch, e la sua push protection lavora lato server. Questo ne fa una buona rete di sicurezza, ma poco adatta al codice che vive altrove. Cosa intercetta e cosa si lascia sfuggire in un flusso di lavoro con Copilot lo trovi nella nostra guida ai rischi di sicurezza di GitHub Copilot.

Il README di ggshield dice che per usarlo «devi autenticarti sui server di GitGuardian», con un account o una API key, e precisa che i tuoi file e i tuoi segreti non verranno conservati. Per molti team è uno scambio ragionevole, ed è uno scambio diverso dal far girare Betterleaks sul tuo runner.

Cosa fare quando uno scanner trova un segreto vero?

Prima lo revochi o lo ruoti, poi decidi se serve riscrivere la history. La guida di GitHub sulla rimozione dei dati sensibili dice che, per una password, un token o una credenziale, il primo passo è revocarli e/o ruotarli, e che un segreto revocato non dà più accesso, il che a volte basta da solo.

1. Revoca o ruota la credenziale presso il provider. Kingfisher, e Betterleaks dalla versione 2, sanno revocare da soli alcuni tipi di credenziali.
2. Controlla nei log di accesso del provider come è stata usata mentre era esposta.
3. Toglila dal codice e spostala in un secrets manager o in una variabile d'ambiente che il codice legge.
4. Riscrivi la history solo se devi; la guida di GitHub spiega i passaggi.
5. Registra i falsi positivi, così smettono di tornare: un commento gitleaks:allow o betterleaks:allow, una voce nel file di ignore dello strumento, oppure una baseline di detect-secrets.

Domande frequenti

Qual è il miglior secret scanner open source nel 2026?

Nel nostro test del 29 ottobre 2026, Betterleaks 1.9.0 ha trovato tutte e 12 le credenziali piazzate in un piccolo repository e non ha dato allarmi sulle esche. TruffleHog è la scelta più forte quando ti serve sapere se una chiave è attiva, perché verifica di default. Gitleaks funziona ancora, e il suo README limita le prossime release alle patch di sicurezza.

TruffleHog o Gitleaks: quale scegliere?

Dipende da cosa ti serve dopo il match. TruffleHog verifica di default se una credenziale è attiva e con --results=verified tiene solo quelle confermate; nel nostro test ne ha trovate 9 su 12. Gitleaks non verifica nulla, ne ha trovate 10 su 12 e riceve solo patch di sicurezza. Per un setup nuovo c'è Betterleaks, che legge la configurazione di Gitleaks.

Gitleaks è ancora mantenuto?

Gitleaks è ancora mantenuto, ma solo con patch di sicurezza. Dal 21 maggio 2026 il suo README dice che è completo nelle funzionalità e che non verranno integrate nuove feature; l'ultima release è la v8.30.1 del 21 marzo 2026. Il suo autore originale ora lavora su Betterleaks, che legge i file di configurazione di Gitleaks e i suoi commenti allow.

Cos'è Betterleaks?

Betterleaks è uno scanner di segreti con licenza MIT, creato a febbraio 2026 da chi ha fatto Gitleaks, tra cui il suo autore originale, con uno sviluppo sostenuto da Aikido Security. La 1.9.0 è la release stabile. La versione 2 è in release candidate, lascia la validazione live disattivata di default e rimuove il reporter SARIF.

TruffleHog è gratis? È open source?

Sì. TruffleHog su GitHub è open source con licenza AGPL-3.0 dalla versione 3.0, e si usa gratis. Dichiara oltre 800 tipi di segreti, verifica di default le credenziali presso i loro provider e scrive SARIF dalla versione 3.97.0, uscita ad agosto 2026.

detect-secrets controlla anche la history di git?

No, per scelta. detect-secrets analizza i file del tuo working tree, di default quelli tracciati da git, e tiene una baseline delle segnalazioni note, così solo i segreti nuovi bloccano un commit. Nel nostro test si è perso una chiave che esisteva solo nella history di un file cancellato. La sua ultima release, la 1.5.0, è di maggio 2024.

Come trovare le API key hardcoded nel codice sorgente?

Fai girare uno scanner basato su pattern come Betterleaks o Gitleaks sul codice e su tutta la history di git una prima volta, poi a ogni commit e a ogni push. Le chiavi dei provider come AWS, GitHub o Stripe vengono riconosciute da prefisso e formato. I segreti generici, come le password, richiedono regole sui nomi delle variabili e sull'entropia, ed è lì che gli strumenti si differenziano di più.

Il secret scanning di GitHub è gratis?

Sui repository pubblici sì: il secret scanning gira in automatico e gratis. Sui repository privati e interni di un'organizzazione richiede GitHub Secret Protection su GitHub Team o GitHub Enterprise Cloud, fatturato per committer attivo.