BLOCCO PRE-COMMIT — Repository: backend-api, branch: feature/auth-refactor. Trovata credenziale in chiaro: file config/test.env, riga 23. Formato compatibile con API key del servizio di pagamento. Livello: critico. Soluzione: spostare nel vault aziendale e referenziare con process.env.PAYMENT_API_KEY.
AGENTE · SECRET DETECTION
Le credenziali in chiaro nei repository vengono trovate prima dei cattivi.
Secret Detection scansiona i repository del cliente alla ricerca di credenziali in chiaro: API key, token di accesso, password, certificati privati, connection string. Si attiva su ogni nuovo commit (pre-commit hook) e in scansione giornaliera completa del repository. Alert immediato al security team.
Secret Detection al lavoro.
Corretto. Spostate nel vault, aggiornato il file di configurazione. Ricommit.
Commit autorizzato. Nessuna credenziale in chiaro rilevata. Evento registrato nel log audit.
Perché esiste.
Le credenziali in chiaro nei repository sono uno dei rischi di sicurezza più comuni nelle aziende che fanno sviluppo software. Uno sviluppatore commette per errore un file con una chiave API, un token di accesso, una password di database; il file finisce nel repository, accessibile a chi ha accesso al progetto. Le credenziali esposte sono utilizzabili per attacchi reali.
Come lavora su due fronti.
Pre-commit hook: si attiva al momento del commit dello sviluppatore, scansiona il diff per pattern di credenziali in chiaro, blocca il commit con messaggio strutturato che indica il pattern trovato e propone la soluzione (variabile d'ambiente, vault aziendale, file di configurazione esterno). Scansione giornaliera completa: si attiva con schedulazione giornaliera sull'intero repository per identificare credenziali residue da errori passati che il pre-commit hook non ha intercettato.
La decisione resta al team.
Il security team decide la gestione dell'incident (revoca della credenziale esposta, rotazione, comunicazione al cliente del servizio compromesso). Il blocco pre-commit è strutturale per evitare che credenziali esposte raggiungano il repository remoto.
Tre figure tecniche che cambiano il modo di gestire le credenziali.
Responsabile sicurezza informatica
Recupera il tempo della revisione manuale dei repository. La scansione automatica copre il volume.
10 controlli attivi
policy.evaluate 14:02:11 ALLOW
pii-detector 14:01:58 BLOCK
tool.invoke 14:01:42 WARN
memory.write 14:01:09 BLOCK
Responsabile DevOps
Vede ridursi gli incident di sicurezza causati da credenziali esposte, fra le fonti principali di compromissione nelle aziende mid-large.
Proposta n. 2024-081 In revisione
Disclosure mancante
art. 21 TUF · strumento finanziario regolato
Alt. 1 …nel rispetto dell'art. 21 TUF e delle disposizioni Consob vigenti.
Alt. 2 …con disclosure completa allegata al documento di offerta.
Traccia audit registrata · 14:31
Sviluppatore
Riceve feedback immediato al commit, non a distanza di settimane. La curva di apprendimento sul corretto uso dei vault e delle variabili d'ambiente accelera.
$ git clone github.com/polyant-ai/polyant
$ cd polyant
$ docker compose up -d
polyant agent runtime · active
AGPLv3 · codice nel perimetro del cliente
Un commit bloccato, una rotazione, due fronti che lavorano.
Il commit si blocca al pattern critico.
Per un'azienda B2B SaaS con 25 sviluppatori, l'agente è integrato con il repository GitHub via webhook e schedulazione giornaliera. Uno sviluppatore commette una modifica che include un file di configurazione di test con la chiave API di un servizio di terze parti. Il pre-commit hook attiva l'agente. L'agente scansiona il diff. Identifica il pattern: stringa formattata come API key. Il pattern viene riconosciuto come credenziale in chiaro, livello critico. Il commit viene bloccato con messaggio strutturato: file e riga trovati, soluzione raccomandata.
Vault, riferimento, ricommit.
Lo sviluppatore sposta la credenziale nel vault del progetto, modifica il file per usare la referenza al vault, ricommette. Il commit passa.
Le credenziali residue dal passato emergono dal log.
In parallelo, la scansione giornaliera notturna identifica due credenziali residue in file di test legacy (commit precedenti, prima dell'integrazione dell'agente). Alert al security team con riferimento ai file. Il team decide la rotazione delle credenziali compromesse e la pulizia dei file dal repository.
Pattern e allowlist dichiarativi del team security.
Le regole sono dichiarative. Il team security definisce in formato leggibile i pattern di credenziali da riconoscere (API key di servizi specifici, formati di token, formati di connection string), le soglie di alert, il flusso di gestione dell'incident. Le regole vivono nel repository del cliente, versionate, validate all'avvio dell'agente.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector (7 pattern nativi: API key, JWT, AWS keys, PEM, connection string), prompt-injection
- Canali nativi
- Slack, Telegram, HTTP OpenAI-compatible (webhook git pre-commit)
- Integrazione GitHub, GitLab, Bitbucket
- tool ghPR/ghIssue nativi per GitHub, adapter dedicato in delivery per altri sistemi
- Memoria
- persistente per istanza
- Registro
- immutabile, interrogabile con client SQL standard
Domande frequenti sull'agente.
Il controllo credential-detector è uno dei dieci controlli built-in del runtime e applica 7 pattern al testo che esce dal runtime di un agente. Secret Detection è un agente dedicato che applica la stessa logica (più altri pattern dichiarativi) alla scansione dei repository. I due lavorano in due punti diversi: il controllo runtime protegge l'output dell'agente, Secret Detection protegge il codice del progetto.
Per il pre-commit hook, sì: il commit viene bloccato quando l'agente identifica una credenziale in chiaro. Lo sviluppatore deve rimuovere la credenziale e ricommettere. Il blocco è strutturale per evitare che credenziali esposte raggiungano il repository remoto.
I pattern di falsi positivi (es. valori di test che assomigliano a API key ma sono dichiaratamente fittizi) possono essere marcati dal team con commenti specifici nel codice o regole di allowlist nel repository. L'agente impara dai pattern del repository del cliente.
Il pattern tipico per Secret Detection è 3-6 settimane. Discovery una settimana, configurazione regole di pattern e allowlist 1-2 settimane, integrazione con i repository del cliente 1-2 settimane, hand-off al team security 1 settimana.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Secret Detection si configurerebbe sul caso del cliente. Repository, pattern di credenziali, soglie del team.