GitHub CodeQL ora cerca le prompt injection nel codice

Il 10 luglio 2026 GitHub ha pubblicato CodeQL 2.26.0, versione che aggiunge il supporto a Kotlin 2.4.0 e nuove capacità di rilevamento delle prompt injection. CodeQL è il motore di analisi statica utilizzato da GitHub code scanning: tratta il codice come dati interrogabili e cerca percorsi che collegano fonti non affidabili a operazioni sensibili. Applicare questo modello alle applicazioni AI significa osservare dove testo proveniente da utenti, web, documenti o strumenti può influenzare istruzioni e azioni del modello.

La novità è rilevante perché molte vulnerabilità LLM non sono contenute nel testo del system prompt. Nascono dall’architettura: un’app recupera una pagina esterna, la concatena alle istruzioni e concede al modello la possibilità di chiamare strumenti. Un contenuto malevolo può allora tentare di cambiare priorità, estrarre informazioni o indurre un’azione. L’analisi del flusso aiuta a individuare combinazioni pericolose già nel repository, prima che un red team incontri il caso durante un test manuale.

CodeQL non rende sicura automaticamente un’applicazione. Le query riconoscono pattern modellati e possono generare falsi positivi o non coprire un’integrazione particolare. Il valore sta nel portare il tema dentro una pratica esistente: pull request, alert, assegnazione e remediation. La sicurezza AI smette di essere un controllo speciale affidato a pochi esperti e diventa una proprietà che il team può discutere accanto a injection tradizionali, gestione dei segreti e autorizzazioni.

Una prompt injection avviene quando contenuto controllato da un attaccante influenza il comportamento di un modello in modo non previsto. Può essere diretta, attraverso un messaggio dell’utente, oppure indiretta, nascosta in una pagina, un documento, un’email o un record recuperato dall’applicazione. Il modello non possiede una separazione perfetta tra dati e istruzioni: interpreta tutto come sequenze linguistiche. Frasi inserite nel contesto possono quindi competere con le regole definite dallo sviluppatore.

Il rischio cresce quando il modello può agire. Un chatbot che risponde male crea un problema di qualità; un agente con accesso a posta, file o sistemi aziendali può produrre conseguenze. Un documento malevolo potrebbe chiedere di ignorare l’obiettivo, recuperare dati riservati o inviare contenuti a un endpoint esterno. Anche se il modello rifiuta spesso, la sicurezza non può dipendere dalla probabilità di obbedienza. Le capacità disponibili devono essere limitate indipendentemente dal testo ricevuto.

È importante distinguere prompt injection e jailbreak. I termini si sovrappongono, ma nella progettazione applicativa l’injection riguarda soprattutto input non fidati che attraversano il sistema e alterano un task. Pensare in termini di data flow aiuta: da dove arriva il contenuto, quali trasformazioni subisce, in quale prompt entra e quali sink può raggiungere? Questa mappa consente controlli tecnici più concreti di un semplice invito al modello a non seguire istruzioni sospette.

L’analisi statica esamina il codice senza eseguire l’applicazione. CodeQL modella fonti, trasformazioni e destinazioni sensibili per ricostruire percorsi. Nel caso AI, una fonte può essere un parametro HTTP, un contenuto recuperato o un file caricato; una destinazione può essere la costruzione di un prompt o una chiamata che permette azioni. Se tra i due non esistono validazioni, separazioni o controlli riconosciuti, il sistema può generare un alert con il percorso interessato.

Questo approccio è particolarmente utile nei progetti grandi, dove il prompt finale viene assemblato in più moduli. Uno sviluppatore può controllare una funzione senza sapere che un valore deriva da una pagina esterna. Il data flow rende visibile la relazione. Aiuta anche durante le revisioni: invece di discutere genericamente se un prompt è robusto, il team osserva quale input può raggiungerlo e cosa succede dopo. La conversazione passa dal linguaggio alla superficie di attacco.

Ci sono limiti inevitabili. Framework proprietari, costruzioni dinamiche e wrapper interni possono non essere modellati. Alcune sanitizzazioni non eliminano davvero un’istruzione linguistica, mentre il tool potrebbe interpretarle come barriera; al contrario, controlli applicativi solidi potrebbero non essere riconosciuti. Per questo ogni alert richiede contesto e le query vanno estese quando il progetto usa pattern specifici. L’analisi è una rete di sicurezza, non un certificato assoluto.

La prima difesa è ridurre la confusione tra contenuto e comandi. I dati recuperati vanno delimitati e descritti come non attendibili, evitando di inserirli nello stesso blocco delle regole più sensibili. Quando possibile, il modello deve estrarre informazioni in uno schema ristretto anziché interpretare liberamente un documento. Un secondo componente può verificare il risultato prima dell’uso. Questa separazione non impedisce ogni attacco, ma limita la possibilità che una frase nascosta diventi automaticamente una decisione operativa.

Gli strumenti concessi all’agente devono applicare autorizzazioni proprie. Se il modello chiede di inviare un’email, l’API deve controllare destinatario, ruolo, ambito e approvazione. Non è sufficiente che il system prompt dica di non inviare dati sensibili. Le regole di sicurezza devono vivere nel codice e nei sistemi che eseguono l’azione. La distinzione è fondamentale: il modello propone un’intenzione, mentre un livello deterministico decide se l’azione è consentita.

Riducete anche il contesto. Un agente non dovrebbe ricevere tutti i documenti o tutte le credenziali per comodità. Recupero mirato, scope per task e token temporanei diminuiscono l’impatto di un’injection riuscita. Per operazioni irreversibili inserite conferma umana con un riepilogo comprensibile di dati e destinazione. Il sistema più sicuro non è quello che convince sempre il modello a comportarsi bene, ma quello che rimane protetto anche quando il modello interpreta male un input.

Iniziate abilitando code scanning sul repository e definendo i linguaggi supportati. Eseguite una scansione di base sul branch principale, poi attivate il controllo nelle pull request. Gli alert nuovi dovrebbero bloccare la fusione quando raggiungono una severità concordata, mentre il debito storico può essere gestito con una roadmap separata. Questo evita che centinaia di segnalazioni iniziali paralizzino il team e mantiene chiara la regola: il codice nuovo non deve peggiorare la postura.

Ogni alert AI va assegnato a chi conosce il flusso applicativo. Il triage dovrebbe annotare fonte non fidata, sink, capacità dell’agente e barriere esistenti. Se si tratta di un falso positivo, documentate la motivazione e preferite una soppressione locale e motivata a una regola globale. Le decisioni diventano materiale per la revisione successiva. Un registro leggero aiuta a identificare pattern ricorrenti e a migliorare componenti condivisi invece di correggere lo stesso problema in più repository.

Aggiungete test di regressione quando correggete. Se un percorso permetteva a un documento di influenzare una chiamata, create un caso che simuli l’input e verifichi il blocco. L’analisi statica impedisce la ricomparsa del pattern nel codice; il test runtime controlla il comportamento effettivo. Insieme offrono una copertura più forte. Le query e i modelli vanno aggiornati con le versioni di CodeQL, leggendo changelog e note per capire nuovi alert o cambiamenti di precisione.

Le prompt injection dipendono dal comportamento del modello e dal contenuto, quindi richiedono test dinamici. Costruite una libreria di attacchi diretti e indiretti: istruzioni nascoste in HTML, documenti, campi strutturati e risultati di ricerca. Variate lingua, encoding e posizione. Il test non deve misurare soltanto se il modello ripete un segreto, ma se prova a usare strumenti, modifica parametri o espone dati attraverso l’output. Ogni capacità operativa ha scenari specifici.

Il red team deve lavorare su un ambiente isolato con dati sintetici e strumenti finti. Registrate prompt, contesto, chiamate e decisioni dei controlli. Senza tracce è difficile capire se la difesa ha funzionato per il motivo previsto o per casualità. Un attacco fallito oggi potrebbe riuscire con un modello diverso. L’obiettivo è verificare i confini deterministici: anche se il modello viene persuaso, l’azione pericolosa deve essere negata o richiedere approvazione.

In produzione, monitorate anomalie come richieste di strumenti inattese, accessi fuori scope, output contenenti token sentinella e picchi di rifiuti. Evitate di registrare dati sensibili senza necessità; mascherate e limitate l’accesso ai log. Definite una procedura per sospendere capacità o integrazioni. La risposta rapida conta perché un agente può agire più velocemente di un flusso umano. Osservabilità e kill switch sono parti del prodotto, non opzioni operative da aggiungere dopo il lancio.

La sicurezza AI attraversa sviluppo, prodotto, dati e operations. Il product manager definisce quali azioni sono necessarie; lo sviluppatore implementa confini; il security team modella minacce; chi gestisce i dati decide accessi e retention. Se il rischio viene assegnato soltanto al prompt engineer, molte difese restano fuori campo. Una revisione delle capacità prima del rilascio dovrebbe elencare fonti non fidate, strumenti, autorizzazioni e conseguenze massime di un errore.

Serve anche formazione per la code review. Gli sviluppatori devono riconoscere concatenazioni di contenuto, recuperi troppo ampi e tool che si fidano del modello. Checklist brevi sono più efficaci di documenti teorici. Domande come ‘questo valore può contenere istruzioni?’, ‘chi autorizza l’azione?’ e ‘cosa vede il modello che non serve?’ portano alla luce problemi concreti. CodeQL può indicare un percorso, ma il team deve sapere interpretare il rischio e scegliere una correzione architetturale.

Per i fornitori esterni, chiedete documentazione su prompt injection, permessi, logging e incident response. Se un SDK nasconde la costruzione del prompt o concede strumenti in modo implicito, il vostro controllo diminuisce. Preferite componenti che espongono confini e permettono test. Nei contratti, chiarite responsabilità e tempi di notifica. La sicurezza di un agente dipende dall’intera catena, inclusi modelli, plugin, dati e sistemi a valle.

Mappate tutte le fonti non fidate, incluse quelle apparentemente interne. Definite per ogni strumento scope, autorizzazioni e azioni irreversibili. Separate istruzioni e contenuti, limitate il contesto e applicate output strutturati. Eseguite CodeQL e risolvete gli alert pertinenti. Aggiungete test di injection e casi limite. Verificate che i log permettano di ricostruire una sessione senza esporre segreti. Infine, nominate chi può disattivare strumenti o tornare alla modalità manuale.

Fate una prova di incidente. Inserite un documento malevolo in un dataset di test e osservate rilevamento, blocco, alert e comunicazione. Misurate quanto tempo serve per capire cosa è accaduto. Le simulazioni fanno emergere dipendenze nascoste: un log non accessibile, un account senza proprietario o un kill switch che richiede un deploy. Correggere questi problemi prima del lancio vale più di una promessa astratta di robustezza del modello.

L’aggiunta delle prompt injection a CodeQL è un segnale di maturità dell’ecosistema. I rischi AI stanno entrando negli strumenti standard di ingegneria. Questo non li rende risolti, ma li rende più visibili e gestibili. Le organizzazioni che combinano analisi statica, architettura a minimo privilegio, test e monitoraggio possono costruire agenti utili senza affidare la sicurezza alla speranza che il modello ignori sempre l’istruzione sbagliata.