Sicurezza e audit del codice 🔒

La sicurezza è il dominio dove l’agente è più utile come assistente e più pericoloso come sostituto. Può scansionare codice per secret, pattern vulnerabili e configurazioni insicure in pochi secondi. Ma non capisce il contesto aziendale, non conosce le threat model del tuo sistema, e non sostituisce mai la review umana. Questa guida definisce come usare l’agente per la sicurezza nel ciclo di sviluppo, non come fare security engineering in generale.

L’agente può trovare ciò che dimentichi. Non può decidere cosa è davvero pericoloso.

Confini con altri contenuti 📐

Questa guida non duplica la guida esistente Audit di sicurezza con AI generativa. Quella guida si concentra sul prompting per audit di sicurezza con LLM generici. Questa guida si concentra sul workflow dell’agente di coding: come integrare la sicurezza nel ciclo di sviluppo, come gestire i rischi specifici degli agenti (prompt injection, excessive agency, supply chain MCP), e quando fermarsi.

Quando usare l’agente per questo caso 🎯

• Secret scanning — cercare credenziali hardcoded, API key, token JWT nel codice.
• Analisi di diff — revisione di modifiche per pattern vulnerabili prima del merge.
• Scansione pre-commit — audit rapido prima di ogni commit.
• Verifica dipendenze — controllare che le librerie introdotte siano legittime.
• Aggiornamento policy — generare o aggiornare .gitignore, .ignore, regole di sicurezza.

Quando NON usare l’agente ⛔

• Threat modeling completo — serve conoscenza del dominio aziendale.
• Audit di conformità — GDPR, PCI-DSS, SOC2 richiedono competenze specialistiche.
• Penetration testing — l’agente non può eseguire test di invasione.
• Revisione di architettura di sicurezza — decisioni di design, non scanning di codice.

Prompt di apertura 📝

“Scansiona [area/file] per: secret hardcoded, SQL injection, path traversal, XSS, credenziali in chiaro. Segnala con severità (CRITICA/ALTA/MEDIA/BASSA) e file:riga. NON applicare modifiche.”

Esempio concreto:

“Scansiona src/ per: (1) API key, token, password hardcoded; (2) query SQL non parametrizzate; (3) path traversal in input utente; (4) config con secret in chiaro. Segnala con severità e posizione esatta. NON applicare modifiche.”

Flusso di lavoro 🔧

1. Configurazione dei filtri 🛡️

Prima di tutto, assicurati che i segreti non entrino nella sessione dell’agente. Configura .gitignore e .ignore per escludere file sensibili.

# .gitignore — pattern essenziali
.env
.env.*
*.key
*.pem
credentials.json
service-account*.json

Se l’agente legge un file .env con chiavi reali, quelle chiavi finiscono nel contesto della sessione. OWASP LLM02 classifica la divulgazione di dati sensibili come rischio critico.

2. Scansione dei segreti 🔑

Chiedi all’agente di cercare specificamente credenziali e segreti nel codice.

“Cerca nel codice: API key (AWS, GitHub, OpenAI, Stripe), token JWT, password hardcoded, certificati .pem, connection string con credenziali. Segnala ogni occorrenza con file:riga.”

3. Analisi dei pattern vulnerabili 🕵️

Richiedi l’analisi per le categorie OWASP principali:

• SQL Injection — query concatenane con input utente
• Command Injection — esecuzione comandi shell con input non sanitizzato
• Path Traversal — accesso a file con percorsi costruiti da input
• XSS — rendering di HTML non sanitizzato
• Hardcoded Credentials — segreti nel codice sorgente

“Analizza il codice rispetto a: SQL injection (query non parametrizzate), command injection (exec con input), path traversal (file access con input), XSS (HTML non sanitizzato). Per ogni vulnerabilità: severità, file:riga, descrizione, remediation.”

4. Verifica delle dipendenze 📦

Controlla che le librerie introdotte dall’agente siano legittime e non compromesse.

“Elenca tutte le dipendenze esterne importate nei file modificati. Per ogni dipendenza: verifica l’esistenza su registro ufficiale (npm, PyPI, Crates.io), segnala eventuali pacchetti insoliti o potenzialmente hallucinati.”

Questo passaggio protegge da slopsquatting: l’agente potrebbe inventare nomi di pacchetti che esistono ma sono malevoli.

5. Audit delle integrazioni MCP 🔌

Se il progetto usa server MCP, verifica che rispettino il principio del minimo privilegio.

“Ispeziona la configurazione MCP del progetto. Identifica server che concedono permessi di scrittura non vincolati o capacità di eseguire comandi shell arbitrari. Suggerisci regole di gating per operazioni ad alto impatto.”

6. Report e correzione 📝

Genera un report strutturato e applica le correzioni.

“Genera un report tabellare: Severità | File:Riga | Categoria OWASP | Rischio | Remediation. Poi applica le correzioni per i problemi CRITICI e ALTI.”

Template di prompt 📋

Template 1 — Audit completo

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

CONTESTO: Sei un Senior Application Security Auditor. Esegui un audit di sicurezza su [FILE/DIFF].
Il codice è stato generato o modificato da un agente di programmazione.

TASK: Analizza rispetto a:
1. Hardcoded Secrets (OWASP LLM02): API key, token, password in chiaro
2. Injections (OWASP LLM05): SQL, command, path traversal, XSS
3. Supply Chain (OWASP LLM03): dipendenze esterne, pacchetti hallucinati
4. Access Control: autorizzazioni bypassabili

FORMATO: Report tabellare con Severità (CRITICA/ALTA/MEDIA/BASSA), File:Riga, Categoria OWASP, Rischio, Remediation.

Template 2 — Audit MCP

1
2
3
4
5
6
7
8

CONTESTO: Valuta la sicurezza delle integrazioni MCP configurate.
CONFIGURAZIONE: [file MCP]

TASK:
1. Ispeziona comandi esposti dai server MCP registrati
2. Identifica agenzia eccessiva (OWASP LLM06)
3. Verifica vettori di Indirect Prompt Injection (OWASP LLM01)
4. Suggerisci regole di gating human-in-the-loop

OWASP Top 10 for LLM Applications 2025 📖

Riferimento rapido per le categorie più rilevanti nel contesto agenti di coding:

Anti-pattern 🚫

• Fidarsi ciecamente dell’agente — non correggere codice solo perché “l’AI l’ha generato sicuro”. Serve sempre un audit finale umano.
• Ignorare OWASP — non controllare l’output vs le categorie standard.
• Passare dati sensibili nel prompt — includere file .env reali nella sessione.
• Skill/plugin non attendibili — installare agenti o skill da fonti sconosciute.
• Delegare completamente la security review — il 45% del codice generato da AI contiene vulnerabilità (Veracode). L’agente è un prerevisione, non la revisione finale.
• Trascurare le dipendenze — anche in sicurezza, usare scanner per pacchetti.

Criteri di accettazione 📏

Riferimenti della serie 📚

• Audit di sicurezza con AI generativa — prompting per audit (confini della serie)
• Configuring the repository — .gitignore, .ignore, configurazione
• Code review assistita — review di sicurezza come parte della code review
• Skills, hooks e MCP — sicurezza delle integrazioni MCP