Audit di sicurezza per applicazioni create con AI: cosa include e cosa no

Chi chiede un audit di sicurezza per un’app creata con AI si trova spesso davanti a due domande concrete: cosa verrà controllato davvero e cosa resta fuori dal perimetro. La risposta dipende dal tipo di app: una web app classica generata con AI richiede WAPT, Code Review e verifica delle configurazioni; un’app che integra LLM richiede anche test su prompt, RAG, tool call e output.

Il punto non è giudicare l’AI come strumento di sviluppo. È molto più pratico: capire quali controlli servono quando codice o workflow generati o accelerati dall’AI entrano in un prodotto, in un processo aziendale o in un ambiente con dati reali.

Perché un’app che funziona non è necessariamente sicura

Gli strumenti AI riducono il tempo necessario per creare codice, interfacce, workflow e configurazioni. Questa velocità può però comprimere passaggi che normalmente rendono il software affidabile: threat modeling, review, gestione dei segreti, controlli sui ruoli, validazione degli input, verifica delle dipendenze e test manuale dei percorsi critici.

Una demo funziona con un solo utente, dati fittizi e permessi impliciti. La stessa logica può fallire quando arrivano clienti reali, tenant multipli, ruoli diversi, API pubbliche, integrazioni, dati personali, pagamenti o automazioni con effetti esterni. La sicurezza va valutata sul comportamento reale dell’app, non sulla promessa del tool che l’ha generata.

Cosa serve per avviare un audit

Per condurre un audit serio servono: repository o build, URL e ambienti di test, definizione dei ruoli utente, flussi critici, schema dati, integrazioni esterne, pipeline CI/CD, configurazioni cloud rilevanti e indicazione di quali parti siano state generate o modificate con AI.

Cosa include un audit proporzionato

Un audit proporzionato copre autenticazione, autorizzazioni, API, gestione dei dati, segreti, dipendenze, configurazioni, logging, error handling, pipeline e superfici esposte. Se l’app usa LLM, include anche prompt injection, output handling, retrieval, memoria, tool call e rate limit.

Cosa non include

Un audit non è una certificazione del tool AI usato per sviluppare, non garantisce l’assenza di bug futuri e non sostituisce governance, monitoring, patching e remediation continuativa. Senza accesso a codice, ruoli e un ambiente rappresentativo della produzione, l’audit diventa inevitabilmente parziale.

Rischi principali da controllare

• Perimetro ambiguo tra WAPT, Code Review, VA e AI testing: definire in anticipo quali superfici rientrano nel test e quali no.
• Ambiente di test non rappresentativo della produzione: dati fittizi e permessi semplificati nascondono vulnerabilità reali.
• Ruoli e dati non forniti al tester: senza accesso ai ruoli reali, i controlli sulle autorizzazioni restano incompleti.
• Codice generato non tracciato nei diff: le parti generate con AI non revisionate manualmente sono un punto cieco.
• Rischi LLM ignorati per app che usano modelli: prompt injection, tool call non controllate e output non validati sono vettori concreti.
• Rischi classici ignorati perché l’app è “AI”: autenticazione, autorizzazioni e gestione dei segreti restano critici indipendentemente da come è stato scritto il codice.
• Deliverable senza priorità di remediation: un report senza distinzione tra finding bloccanti e rischio residuo non supporta decisioni operative.

La combinazione corretta di controlli dipende dall’impatto, non dal nome del tool. Un’app esposta richiede test applicativi manuali; una modifica critica al codice richiede review; un workflow interno richiede controllo di permessi e credenziali; un’app agentica richiede test su prompt, tool e output.

Controlli minimi prima del go-live

• Mappare utenti, ruoli, dati reali, integrazioni, ambienti e owner del servizio.
• Identificare quali parti sono state generate o modificate con AI e chi le ha revisionate.
• Verificare autorizzazioni server-side, tenant isolation e funzioni amministrative.
• Cercare segreti in codice, prompt, log, variabili d’ambiente, build e cronologia repository.
• Controllare dipendenze, licenze, pacchetti, template, plugin e componenti generati.
• Testare input ostili, error handling, logging, rate limit e percorsi non previsti.
• Separare fix bloccanti, remediation pianificata e rischio residuo accettato consapevolmente.
• Ripetere il test o il retest dopo correzioni che toccano flussi critici.

Quando serve una verifica indipendente

Serve una verifica indipendente quando l’app o il workflow gestisce dati reali, utenti esterni, ruoli, API, integrazioni aziendali, pagamenti, storage, workflow automatici o codice critico generato con AI. Serve anche quando il team non riesce a dimostrare quali parti siano state revisionate e quali controlli blocchino regressioni o abusi.

Il perimetro consigliato da ISGroup in questo caso comprende: Web Application Penetration Testing, Code Review, Vulnerability Assessment e, per le app con LLM, AI Application Testing. La review migliore produce finding riproducibili, priorità di remediation, indicazione del rischio residuo e, quando necessario, retest dopo le correzioni.

Domande operative per founder, CTO e security team

• Quali dati reali entrano nel sistema e dove vengono salvati, loggati o inviati?
• Quali ruoli esistono e quali azioni sono bloccate lato server, non solo nell’interfaccia?
• Quali segreti, token, webhook o credenziali permetterebbero accesso a sistemi critici?
• Quali parti sono state generate o modificate dall’AI e quali sono state revisionate da una persona competente?
• Quali test coprono abuso, errori, ruoli diversi e tenant diversi, non solo il percorso felice?
• Quale evidenza può essere mostrata a clienti, audit, procurement o direzione?

Approfondimenti utili

• Penetration test per SaaS e app AI: come impostare un test su prodotti SaaS o applicazioni che integrano componenti AI, con focus su perimetro e metodologia.
• Controlli di sicurezza per app AI prima del go-live: lista operativa dei controlli da completare prima di portare online un’app sviluppata con AI.
• AI Application Testing: approfondimento sui test specifici per applicazioni che integrano LLM, agenti e workflow autonomi.

FAQ

• Che differenza c’è tra audit, WAPT e Code Review?
• Il WAPT verifica il comportamento dell’app esposta simulando un attaccante esterno. La Code Review analizza il codice sorgente alla ricerca di vulnerabilità logiche e bad practice. L’audit combina controlli proporzionati al perimetro e può includere configurazioni, processo e rischi AI-specific.
• Quando serve AI Application Testing?
• Quando l’app integra LLM, RAG, agenti, tool calling, memoria o workflow autonomi. Se l’AI è stata usata solo per scrivere codice, di solito i controlli prioritari restano WAPT e Code Review.
• Quali materiali devo preparare prima dell’audit?
• URL, definizione dei ruoli, flussi critici, repository o build, architettura, integrazioni, dati di test, pipeline CI/CD e lista delle parti generate o modificate con AI.
• Quanto deve essere ampio il perimetro?
• Abbastanza da coprire ciò che può causare impatto reale: dati, utenti, ruoli, API, funzioni amministrative, storage, pagamenti, integrazioni e deploy.
• Il report basta per andare online?
• Solo se i finding bloccanti sono stati corretti o accettati consapevolmente. La decisione finale deve includere una valutazione della remediation completata e del rischio residuo.

Fonti e riferimenti

• OWASP Top 10 2021
• OWASP ASVS
• OWASP Code Review Guide
• NIST SP 800-218 SSDF
• OWASP Top 10 for LLM Applications 2025

Se stai per portare online un’app o un workflow sviluppato con AI, ISGroup può aiutarti a scegliere il controllo giusto: test applicativo, Code Review, assessment architetturale o verifica mirata sui rischi AI-specific.