I quattro rischi principali degli assistenti AI nel lavoro di sicurezza, un metodo per contenerli e un laboratorio che verifica un riepilogo CVE scritto da un'AI confrontandolo con NVD e KEV.
Un assistente AI riassume un record CVE in pochi secondi. Può anche indicare la versione con il fix sbagliata, con lo stesso tono tranquillo che usa per quella giusta. Questo articolo parla di quello scarto: i quattro rischi che pesano di più nel lavoro di sicurezza, un metodo per contenerli e un laboratorio in cui verifichi un riepilogo di esempio scritto da un'AI confrontandolo con il record NVD, il catalogo Known Exploited Vulnerabilities (KEV) di CISA e la pagina di sicurezza di Apache Log4j.
In breve: usa un assistente per il lavoro che puoi controllare, tieni i dati sensibili e le azioni reali fuori dalla sua portata se nessuno li ha approvati, e fai decidere a una persona ogni passo che cambia qualcosa.
Un assistente è un modello linguistico con una casella di testo e, spesso, qualche strumento collegato: una funzione di ricerca, un lettore di file, una shell. Quattro rischi tornano di continuo.
Un modello linguistico produce le parole successive più plausibili. Spesso la risposta plausibile è anche vera. A volte è un numero di versione che suona giusto e non lo è. Il Generative AI Profile del NIST, NIST AI 600-1, la chiama confabulazione: "the production of confidently stated but erroneous or false content." Lo stesso profilo osserva che la confabulazione dipende da come sono costruiti questi modelli e non è un malfunzionamento raro.
Gli identificatori sono i più esposti. Numeri CVE, versioni di pacchetti, date, nomi di funzioni, numeri di RFC e numeri di porta hanno tutti un aspetto strutturato, quindi uno sbagliato sembra verificato. Si copia facilmente in un ticket ed è difficile accorgersene dopo.
Tutto ciò che incolli in un prompt esce dal tuo controllo quando arriva a un servizio che non gestisci tu. Quello che succede dopo dipende dal servizio, dalle sue impostazioni e dai suoi termini. Il testo può essere conservato, registrato nei log o letto da qualcuno. Nel lavoro di sicurezza il materiale a rischio è noto: nomi dei clienti, hostname e intervalli IP interni, token che compaiono nei log, finding non pubblicati e dati personali di un incidente. OWASP lo elenca sotto LLM02:2025 Sensitive Information Disclosure, che copre sia ciò che il modello rivela sia ciò che espone l'applicazione intorno.
Un assistente con la sola casella di testo può darti una risposta sbagliata. Un assistente con una shell, un token API o l'accesso in scrittura a un repository può fare una cosa sbagliata. LLM06:2025 Excessive Agency di OWASP descrive il problema: il sistema ha più funzioni, permessi o autonomia di quanti ne servano per il compito. Quando il modello fraintende una richiesta, il danno dipende da cosa gli era permesso toccare.
La prompt injection avviene quando un contenuto che il sistema legge come dato contiene istruzioni che il modello poi esegue. Il contenuto può essere una pagina web che gli hai chiesto di riassumere, un'email in coda, una riga di log con uno user agent costruito ad arte o il README di un repository da rivedere. OWASP la tratta come LLM01:2025 Prompt Injection. Il profilo del NIST descrive la versione indiretta, in cui un attaccante inserisce istruzioni in dati che l'assistente probabilmente recupererà. L'assistente può non distinguere la tua richiesta dal testo che ha appena letto.
Gli analisti sono le persone che copiano l'output dell'AI in report, regole di rilevamento, ticket e messaggi ai clienti. L'errore viaggia con la copia. Una versione con il fix sbagliata nel tuo riepilogo diventa una decisione di patch sbagliata nella finestra di manutenzione di qualcun altro.
L'AI Risk Management Framework del NIST, pubblicato il 26 gennaio 2023, organizza il lavoro in quattro funzioni: GOVERN, MAP, MEASURE e MANAGE. Non serve avere un programma di AI per riprendere l'idea. Per un singolo analista significa sapere a cosa serve lo strumento, quali dati può vedere, quanto spesso sbaglia sul tuo tipo di compito e chi approva un'azione. Il framework è volontario, e va bene così. Le domande restano valide.
Cinque regole, applicate in ordine ogni volta.
Prima di incollare qualsiasi cosa, dividila in tre gruppi:
I dati riservati restano fuori, a meno che il proprietario dei dati abbia approvato questo uso e la tua organizzazione abbia approvato lo strumento per quella classe di dati. Se ti serve che l'assistente ragioni su un log, oscuralo prima. Per un caso veloce basta un passaggio con sed:
sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/10.x.x.x/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/user@example/g' incident.log > redacted.logEseguilo su una copia, leggi l'output e cerca i casi che la regex non prende: hostname, nomi utente, token e domini interni. Una regex non sa come il tuo cliente chiama i suoi server.
Di' all'assistente di elencare ogni affermazione fattuale con la fonte da cui viene e di scrivere "nessuna fonte" quando non ne ha una. Poi tratta ogni affermazione senza fonte come una domanda a cui devi rispondere tu.
Una citazione nella risposta da sola non prova nulla. Un modello può produrre un link plausibile o una citazione plausibile da un documento che non ha mai aperto. Apri il link. Leggi il paragrafo. Se il paragrafo non dice quello che dice la risposta, la risposta è sbagliata.
I dati primari sono il record di cui parla l'affermazione: la voce NVD di un CVE, il bollettino di sicurezza del vendor, la voce KEV di CISA, il testo dello standard, l'output di un tuo test. Una seconda risposta di un'AI non conta, perché il secondo assistente può ripetere lo stesso errore con la stessa sicurezza. Usa l'assistente per trovare dove guardare. Usa la fonte per decidere.
Parti con l'accesso in sola lettura. Se lo strumento può eseguire comandi, dagli un account con i diritti minimi, una macchina virtuale o un container usa e getta e un'allowlist di comandi. Ogni passo che scrive, invia, cancella o chiama un sistema attivo dovrebbe aspettare una conferma. Conserva il log di ciò che ha eseguito. Ti servirà la prima volta che succede qualcosa di inatteso.
Lo strumento propone. Una persona con contesto e autorità decide, e annota cosa ha approvato e su quali prove. Conta soprattutto per le azioni che non si possono annullare: un intervallo IP bloccato, un ticket chiuso, una patch distribuita in produzione, un messaggio inviato a un cliente.
Questo laboratorio usa solo fonti pubbliche in sola lettura. Non eseguirai nulla contro un sistema attivo. Le tre richieste vanno a NVD, CISA e Apache Software Foundation, e a nessun altro.
Cosa ti serve: un terminale (va bene Git Bash su Windows), curl e jq. Se jq non è installato, installalo dal sito del progetto jq. I comandi qui sotto sono stati eseguiti su Windows 11 con Git Bash. Su quella macchina jq non era installato, quindi gli output mostrati vengono da un comando Node.js che legge gli stessi campi JSON. I comandi da usare sono quelli con jq.
Questo è un riepilogo scritto da un assistente su CVE-2021-44228, la falla nota come Log4Shell. Leggilo prima di controllare qualcosa e segna cosa secondo te è sbagliato.
CVE-2021-44228 is a remote code execution flaw in Apache Log4j2. An attacker who controls a logged value can make the server load code from an LDAP server. NVD published the record on 2021-12-09. The flaw affects Log4j 2.13.0 through 2.14.1, and upgrading to 2.14.1 fixes it. The CVSS v3.1 base score is 10.0. CISA added the flaw to the KEV catalog on 2021-12-10. Attackers began scanning within hours of disclosure. The flaw is in log4j-core only.Il riepilogo contiene due errori voluti. Trovali con le fonti qui sotto.
L'API di NVD restituisce il record CVE in JSON. Esegui questo comando:
curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' | jq '.vulnerabilities[0].cve | {published, descriptions: .descriptions[0].value}'Verifica equivalente senza jq, da cui viene l'output qui sotto:
curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' -o nvd.json
node -e "const c=JSON.parse(require('fs').readFileSync('nvd.json','utf8')).vulnerabilities[0].cve;console.log(JSON.stringify({published:c.published,descriptions:c.descriptions[0].value},null,2))"Output osservato:
{
"published": "2021-12-10T10:15:09.143",
"descriptions": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects."
}Guarda il campo published. Il riepilogo diceva 2021-12-09. Il record dice 2021-12-10. Questo è il primo errore.
La descrizione aggiunge anche una condizione che il riepilogo ha omesso: il codice viene caricato quando la sostituzione dei lookup nei messaggi è attiva. Senza questo dettaglio sembra che la falla colpisca ogni installazione di Log4j, e il record non lo dice.
CISA pubblica il catalogo KEV come un unico file JSON. Scaricalo e filtra il CVE:
curl -s -L 'https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json' -o kev.json
jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228")' kev.jsonOutput osservato, da un catalogo con versione 2026.11.06 e 1769 voci, scaricato il 2026-11-08 (il filtro jq è stato eseguito tramite Node.js, come sopra):
{
"cveID": "CVE-2021-44228",
"vendorProject": "Apache",
"product": "Log4j2",
"vulnerabilityName": "Apache Log4j2 Remote Code Execution Vulnerability",
"dateAdded": "2021-12-10",
"shortDescription": "Apache Log4j2 contains a vulnerability where JNDI features do not protect against attacker-controlled JNDI-related endpoints, allowing for remote code execution.",
"requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available.",
"dueDate": "2021-12-24",
"knownRansomwareCampaignUse": "Known",
"forensicTriage": "No",
"notes": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228",
"cwes": [
"CWE-20",
"CWE-400",
"CWE-502"
]
}La voce conferma l'inserimento in KEV e la data. Non dice nulla su quando sono iniziate le scansioni e non indica una versione con il fix. Usala per l'inserimento, la scadenza e l'azione richiesta, e per nient'altro.
Il record NVD rimanda alla pagina di sicurezza di Apache Log4j. Aprila e trova la sezione di CVE-2021-44228. Leggi quattro campi: Versions affected, Versions fixed, Components affected e la descrizione. Nella versione della pagina scaricata il 2026-11-08, la sezione riportava questi valori:
Leggi la pagina di persona, perché cambia. La pagina ha anche una sezione separata per CVE-2021-45046, un problema successivo, che dice che il fix in 2.15.0 era incompleto in alcune configurazioni e rimanda a 2.16.0 per Java 8 e successivi.
Segna ogni affermazione del riepilogo come confermata, sbagliata o non verificabile. Questo è il risultato della verifica.
| # | Affermazione nel riepilogo | Verdetto | Prova |
|---|---|---|---|
| 1 | Falla di remote code execution in Apache Log4j2 | Confermata | Nome della vulnerabilità in KEV; descrizione NVD |
| 2 | Un attaccante che controlla un valore registrato nel log può far caricare al server codice da LDAP | Confermata (incompleta) | Descrizione NVD, che aggiunge che la sostituzione dei lookup nei messaggi deve essere attiva |
| 3 | NVD ha pubblicato il record il 2021-12-09 | Sbagliata | NVD published: 2021-12-10T10:15:09.143 |
| 4 | La falla colpisce Log4j da 2.13.0 a 2.14.1 | Confermata (incompleta) | Intervallo colpito di Apache [2.13.0, 2.15.0), che copre 2.14.1 ma anche linee più vecchie; anche l'intervallo NVD inizia a 2.13.0 e finisce prima di 2.15.0 |
| 5 | L'aggiornamento a 2.14.1 la corregge | Sbagliata | Apache indica 2.15.0 come fix per Java 8 e successivi; 2.14.1 sta dentro l'intervallo colpito |
| 6 | Il punteggio base CVSS v3.1 è 10.0 | Confermata | Punteggio base CVSS 3.1 di NVD pari a 10; la pagina di Apache indica 10.0 CRITICAL |
| 7 | CISA ha aggiunto la falla a KEV il 2021-12-10 | Confermata | KEV dateAdded: 2021-12-10 |
| 8 | Gli attaccanti hanno iniziato le scansioni poche ore dopo la divulgazione | Non verificabile | Nessuna delle tre fonti indica i tempi delle scansioni |
| 9 | La falla è solo in log4j-core | Confermata | Pagina di Apache: è colpito solo il JAR log4j-core |
Due affermazioni sono sbagliate, una non è verificabile e le altre reggono. Le due sbagliate sono i due errori voluti del riepilogo.
Il testo di NVD e gli intervalli di versione divergono di poco. La descrizione dice "through 2.15.0", mentre l'intervallo leggibile dalle macchine finisce prima di 2.15.0. Sia la configurazione NVD sia la pagina di Apache dicono che 2.15.0 non è colpita da questo CVE su Java 8 e successivi. Quando le fonti non concordano, annota la divergenza e cita quella che definisce l'intervallo. Non scegliere la versione che suona meglio.
La versione con il fix dipende dalla versione di Java e dal CVE. Un unico numero "corretto in" nasconde entrambe le cose. Chiedi il CVE esatto, il prodotto, il componente e la piattaforma, e leggi la tabella del vendor.
Non verificabile è un verdetto utile. Il riepilogo afferma un fatto sui tempi degli attaccanti che nessuna delle tue fonti riporta. Quell'affermazione può essere vera, e può trovarsi in un'altra fonte che non hai letto. In un report, o ha una sua citazione o va tolta.
Costruisci una piccola valutazione per il tuo lavoro. Scegli venti CVE di cui conosci già la risposta, chiedi all'assistente un riepilogo di ciascuno e conta gli errori per tipo: date, versioni, componenti, punteggi. Una verifica così piccola ti dice sui tuoi compiti più della demo di un vendor. Ripetila quando cambia lo strumento o il compito.
Leggi le voci OWASP LLM01, LLM02, LLM06 e LLM09. Danno un vocabolario comune per prompt injection, esposizione dei dati, permessi eccessivi e disinformazione. Poi leggi la sezione 2 di NIST AI 600-1, che definisce i rischi coperti dal profilo.
Se prima di questo materiale vuoi le basi, leggi Cos'è una vulnerabilità? e Cos'è CVSS?. Per esercitarti a scrivere i finding che hai verificato, leggi Come scrivere il tuo primo report di sicurezza. Se mandi lavoro a un modello tramite l'API di NotHoly, le stesse cinque regole valgono per quello che invii.
Sicurezza e governance dell'IA
I termini di servizio di Drael, clausola per clausola: operatore senza nome, nessuna legge applicabile, la sua difesa la paghi tu, rimborsi in credito.
Sicurezza e governance dell'IA
Un account IA senza email sembra privacy. Per un team: nessun avviso di incidente, nessun recupero, nessun offboarding, e meno anonimato di quanto si dice.
Sicurezza e governance dell'IA
Con la prompt injection, il testo in input a un LLM agisce come istruzioni. Attacchi diretti e indiretti, perché non esiste un rimedio completo e le difese a strati.