Guida
Come scansionare il codice generato dall’AI alla ricerca di segreti esposti
Scansiona lo snapshot del repository, verifica l’esposizione nel frontend e controlla a parte la cronologia Git. Cosa rileva vetkit e cosa fare se trapela un segreto.
· 5 min di lettura · A cura del team vetkit
Per scansionare il codice generato dall’AI alla ricerca di segreti esposti, esegui un secret scanner sulla versione del repository che intendi rilasciare, esamina le evidenze con file e riga e revoca ogni credenziale esposta. In vetkit, il Security Quick Scan include il rilevamento dei segreti nel repository; la cronologia Git e l’esposizione delle chiavi lato browser richiedono controlli separati. Un report pulito copre solo i file e i controlli che sono stati effettivamente eseguiti.
1. Scegli il perimetro della scansione
Il codice generato può contenere una credenziale copiata, un segnaposto realistico oppure codice che espone una chiave solo quando fai la build dell’app. Sono problemi diversi. Decidi di quali evidenze hai bisogno prima di interpretare il risultato:
| Domanda | Controllo pertinente | Limite |
|---|---|---|
| C’è una credenziale nei file del repository scansionati? | Segreti (gitleaks), incluso nel Security Quick Scan | Rilevamento basato su pattern nel checkout, non la prova che non ci sia nessuna credenziale |
| Una credenziale è stata cancellata dai file attuali ma è rimasta nei commit? | L’analizzatore separato secrets-history, se disponibile nel perimetro dell’audit selezionato | Cronologia limitata; non fa parte del Quick Scan |
| La configurazione di build potrebbe esporre la chiave di un provider ai browser? | Controlli per app LLM sugli schemi di codice supportati, più una tua ispezione della build | Non fa parte del Quick Scan; un audit del sorgente non ispeziona gli asset che hai in produzione |
2. Scansiona la versione del repository prevista
- Collega il repository in vetkit, poi seleziona il Security Quick Scan o un perimetro di audit disponibile che includa il rilevamento dei segreti.
- Conferma repository e ref di destinazione. Le scansioni dei repository remoti non vedono i buffer non salvati dell’editor né i file locali di cui non hai fatto push. Non committare un sospetto segreto solo per renderlo scansionabile.
- Attendi il completamento e controlla nei risultati degli analizzatori eventuali errori o controlli saltati prima di leggere i risultati. Uno scanner non disponibile non è un controllo superato.
Se lavori tramite un assistente, la guida MCP per Claude Code e Cursor spiega come scegliere un repository ed esaminare i risultati dell’audit. Usa segnaposto nei prompt; non incollare mai una credenziale reale nell’assistente per chiedergli se è valida.
3. Esamina ogni risultato
Leggi regola, gravità, percorso del file e riga. I risultati sui segreti di vetkit usano snippet oscurati; esamina il sorgente in privato per distinguere una credenziale reale da dati di test sintetici. I pattern generici possono produrre falsi positivi, e i formati poco comuni possono sfuggire. Una corrispondenza da sola non stabilisce se la credenziale sia ancora attiva.
Dai la priorità alle credenziali che danno accesso a risorse cloud, repository, pubblicazione di pacchetti o dati di produzione. Registra il servizio interessato e il responsabile della correzione senza copiare il segreto in un ticket, in uno screenshot o in una chat. Non scartare un risultato solo perché l’assistente definisce il valore un esempio.
4. Controlla esposizione nel browser e cronologia
Una chiave può restare fuori da Git e arrivare comunque agli utenti attraverso una build del frontend. Esamina l’uso di variabili d’ambiente pubbliche, le chiamate agli SDK dei provider e la configurazione del bundler, poi ispeziona gli asset generati per il browser in un tuo ambiente controllato. Vedi la guida alle chiavi API nel frontend per alcuni esempi. La scansione del repository non fa automaticamente la build della tua app con i segreti di deploy né esamina i bundle del sito in produzione.
Se una credenziale potrebbe essere stata committata in passato, includi il controllo separato della cronologia dove il perimetro dell’audit lo consente. La sua finestra predefinita è di al massimo 500 commit e può essere più piccola quando la cronologia del checkout è più corta. Non è una ricerca esaustiva su ogni branch, fork o copia del repository.
5. Intervieni e ripeti la scansione
- Revoca o ruota la credenziale esposta presso il suo provider. Cancellare una riga o riscrivere un commit non invalida una chiave già copiata.
- Sposta la nuova credenziale in un archivio di segreti lato server o in un ambiente di runtime adeguato. Assicurati che non possa finire nel codice del browser né essere stampata nei log.
- Esamina i registri di accesso e di utilizzo del provider alla ricerca di attività inattese. Coordina con i collaboratori del repository un’eventuale pulizia della cronologia; la rotazione resta comunque necessaria.
- Esegui una nuova scansione sulla versione corretta e ripeti i controlli pertinenti su build o cronologia. Conserva la versione di destinazione dell’audit insieme alla documentazione della correzione.
Fonti e limiti
Verificato il 1º novembre 2026 sulla configurazione del Quick Scan di vetkit e sulle implementazioni degli analizzatori gitleaks, secrets-history e per app LLM. Il Quick Scan esegue posture, gitleaks e OSV; non include tutti gli analizzatori di un audit completo. L’integrazione con gitleaks salta di default i file più grandi di 5 MB, e le scansioni sono soggette a limiti su repository, file e tempo. Esamina la copertura e gli avvisi dell’esecuzione effettiva.
La documentazione descrive il flusso di audit, e il catalogo pubblico dei controlli documenta le regole proprietarie. Quel catalogo non è un elenco completo delle firme di gitleaks, che sono di terze parti. Questa guida descrive i passaggi di rilevamento e correzione; né una scansione pulita né un punteggio alto garantiscono che un’app sia sicura.