Software house e AI coding: come garantire sicurezza quando il codice è generato da agenti

Per una software house, l’AI coding non è solo un tema di produttività interna: è un tema di affidabilità verso il cliente. Se un team usa agenti per generare codice, refactoring, test, pipeline o configurazioni, deve poter dimostrare che la velocità non ha eliminato review, segregazione dei dati, controlli di sicurezza e responsabilità di delivery.

La domanda che arriva da clienti, procurement e audit è concreta: come sapete che il codice generato o modificato con AI è stato controllato prima della consegna? Una risposta credibile non può essere “ci fidiamo dei nostri developer” o “gli scanner sono verdi”. Serve un programma di assurance: regole interne, evidenze, review, test, gate di pipeline, report e remediation.

Perché il rischio è diverso per una software house

Un team interno può accettare un rischio e governarlo nel proprio ciclo di sviluppo. Una software house, invece, consegna codice a qualcun altro: cliente, audit, procurement, ufficio legale e security team possono chiedere prove in qualsiasi momento.

L’uso di AI coding aggiunge domande nuove che non riguardano solo la qualità tecnica. Quali parti sono state generate o modificate da agenti? Quali dati cliente sono stati usati nel prompt o nel contesto? Quali dipendenze sono state introdotte, e chi ha revisionato il diff? Quali test coprono autorizzazioni, ruoli e abuso? Quali finding sono stati corretti prima della consegna e quali rischi residui sono stati comunicati? Se queste risposte non esistono, la software house perde controllo commerciale oltre che tecnico.

Policy interna per l’uso di AI nei progetti cliente

La policy deve stabilire cosa è ammesso nei progetti cliente, non solo cosa è comodo per il team. Deve coprire strumenti autorizzati, account aziendali, dati vietati, repository ammessi, agent mode, terminale, cloud agent, tool esterni, review e gestione delle eccezioni. I punti minimi da includere sono:

• Nessun account personale su codice o dati cliente.
• Nessun segreto, log reale o dato cliente nei prompt non autorizzati.
• Workspace separati per cliente.
• Esclusione di file sensibili dal contesto dell’agente.
• Approvazione per tool che leggono repository cliente.
• Review obbligatoria su auth, API, dati, pipeline e dipendenze.
• Tracciabilità delle parti AI-generated quando rilevante per il contratto.

La policy deve essere semplice da applicare: se è troppo astratta, ogni team la interpreterà in modo diverso e i controlli perderanno coerenza tra progetti.

Segregazione dei dati cliente

Il rischio più delicato non è sempre il bug nel codice, ma il passaggio non controllato di informazioni tra clienti, tool e ambienti. Una software house deve separare repository e branch, workspace IDE e agenti, ambienti cloud, credenziali, dataset di test, log e ticket, documentazione cliente, prompt e transcript quando sono conservati.

Un agente che lavora su più progetti non deve avere contesto trasversale non necessario. Un dataset cliente non deve diventare una fixture riutilizzata su altri progetti, e un errore di produzione non deve essere incollato in una chat generica con token, email o identificativi non redatti.

Tracciabilità: dal prompt alla release

Non serve salvare ogni prompt in modo indiscriminato, ma è necessario sapere quali decisioni hanno portato alla release. Le evidenze utili da conservare includono issue o task di partenza, PR e commit, file modificati da AI, reviewer e approvazioni, scanner e test eseguiti, nuove dipendenze, modifiche a CI/CD, IaC e deploy, finding e fix, e i rischi residui accettati.

Questa tracciabilità è utile anche internamente: quando emerge una vulnerabilità, quando il cliente chiede spiegazioni o quando una regressione ricompare in una release successiva, avere un percorso documentato riduce significativamente i tempi di risposta.

Review obbligatoria sulle aree sensibili

Non tutto il codice AI-generated ha lo stesso profilo di rischio. Una modifica di copy non richiede lo stesso livello di controllo di una modifica a middleware, ruoli, query, API, pipeline o pagamenti. Una software house dovrebbe definire le aree che richiedono sempre review tecnica:

• Autenticazione, sessioni, password reset, MFA, OAuth.
• Autorizzazioni, ruoli, tenant isolation, policy e middleware.
• API, query, export, upload, pagamenti e webhook.
• Segreti, log, error handling e configurazioni.
• Dipendenze, lockfile, licenze, Dockerfile.
• CI/CD, IaC, cloud, IAM e deploy.
• Prompt runtime, agenti applicativi, RAG e tool calling.

La Code Review diventa così una prova di controllo: non solo “abbiamo letto il codice”, ma “abbiamo verificato queste aree, con questo perimetro e questi risultati”.

Test e scanner: necessari ma non sufficienti

SAST, SCA, secret scanning, test unitari e integration test sono necessari, ma non dimostrano da soli che l’applicazione rispetti business logic, autorizzazioni, tenant isolation e abuso dei ruoli. Per i progetti cliente, la pipeline dovrebbe produrre almeno:

• SAST con triage dei finding nuovi.
• SCA e license scanning su manifest e lockfile.
• Secret scanning su repository, log e artifact.
• Test negativi su ruoli, tenant, input e failure mode.
• Controlli su IaC, container e configurazioni.
• Evidenza di fix e retest.

Quando l’app o le API sono raggiungibili da utenti, partner o internet, è necessario verificare anche il comportamento runtime. In questo contesto il Web Application Penetration Testing completa la Code Review: uno analizza la causa nel codice, l’altro verifica se il comportamento esposto è abusabile sul sistema reale.

Dipendenze, licenze e supply chain

Gli agenti possono aggiungere pacchetti per chiudere velocemente una feature, ma per una software house una dipendenza non è solo un rischio tecnico: può diventare un problema di licenza, manutenzione, vulnerabilità note, policy cliente o audit. Ogni nuova dipendenza dovrebbe essere valutata rispetto a motivazione, versione e lockfile, licenza compatibile, stato di manutenzione, vulnerabilità note, script di installazione e presenza di alternative già nel progetto.

Per clienti enterprise, SBOM, provenance e report SCA possono diventare evidenze contrattuali. Anche quando non sono richiesti esplicitamente, sapere cosa entra nella release riduce i tempi di risposta in caso di CVE.

Report verso il cliente: cosa mostrare

Il cliente non deve ricevere una narrazione generica sull’AI, ma evidenze proporzionate al progetto. Un report utile può includere il perimetro della release o della review, le parti generate o modificate con AI quando rilevante, i controlli eseguiti con scanner e test, i finding bloccanti corretti, i finding pianificabili, i rischi residui, le dipendenze nuove, i limiti del perimetro e le raccomandazioni per le release successive.

Questo non significa esporre ogni prompt o ogni dettaglio interno, ma rendere dimostrabile che il codice consegnato non è stato accettato alla cieca.

Dal progetto singolo al programma di assurance

Il vero salto di qualità arriva quando i controlli non dipendono dal singolo project manager. Ogni progetto con AI coding dovrebbe avere soglie simili, report simili, gate simili e responsabilità chiare. Il Software Assurance Lifecycle serve proprio a questo: trasformare review, test, pipeline, remediation e reporting in un processo ripetibile su team e clienti diversi.

Per una software house, questo ha valore commerciale diretto: aiuta a rispondere a procurement, audit, questionari security e richieste di evidenze senza dover ricostruire il processo da zero ogni volta.

Checklist per software house che usano AI coding

• Policy interna sull’uso AI nei progetti cliente.
• Tool autorizzati, account aziendali e configurazioni minime.
• Separazione di repository, workspace, dati, prompt e credenziali per cliente.
• Divieto di inserire dati cliente, segreti o log sensibili in tool non autorizzati.
• Tracciabilità di PR, commit, review, scanner, test e finding.
• Review obbligatoria su auth, API, dati, pipeline, cloud e dipendenze.
• SAST, SCA, secret scanning e test negativi con soglie definite.
• Controllo licenze e nuove dipendenze.
• Verifica di CI/CD, IaC, container, deploy e rollback.
• Report cliente con perimetro, evidenze, fix e rischio residuo.
• Remediation gestita con owner, severità, SLA e retest.

Quando coinvolgere ISGroup

Una software house può partire da un assessment del processo o da una verifica su un progetto pilota. La scelta dipende dal rischio e dal livello di maturità attuale.

Scenario	Rischio principale	Controllo consigliato
Uso AI coding su più team o clienti	Controlli non ripetibili e audit difficili	Software Assurance Lifecycle
PR AI-generated su codice sensibile	Vulnerabilità o regressioni nel codice	Code Review
Applicazione o API esposta a utenti/clienti	Abuso runtime e vulnerabilità applicative	Web Application Penetration Testing
Cliente richiede evidenze prima della consegna	Perimetro e rischio residuo non dimostrabili	Programma di assurance e report tecnico

Il valore non è solo trovare bug: è rendere difendibile il processo di consegna, documentando cosa è stato controllato, da chi, con quali evidenze e con quali limiti dichiarati.

Domande frequenti

• Una software house deve dichiarare sempre l’uso di AI coding?
• Dipende da contratto, requisiti cliente e policy interne. In pratica conviene essere pronti a spiegare quali strumenti sono usati, quali dati sono esclusi e quali controlli verificano il risultato.
• Il cliente deve vedere i prompt?
• Non necessariamente. I prompt possono contenere informazioni sensibili. Spesso sono più utili policy, perimetro, evidenze di review, test, scanner, finding corretti e rischio residuo.
• Come dimostrare che il codice AI-generated è stato controllato?
• Con evidenze concrete: PR, commit, review, test, report SAST/SCA, secret scanning, dependency report, Code Review, WAPT, finding, fix e retest.
• Quando serve una Code Review indipendente?
• Quando il codice generato o modificato con AI tocca auth, ruoli, API, dati, query, segreti, dipendenze, pipeline, cloud o logica di business critica.
• Quando serve il WAPT oltre alla Code Review?
• Quando l’app è raggiungibile da utenti o clienti. La Code Review analizza il codice sorgente; il WAPT verifica se il comportamento esposto è abusabile in condizioni reali.

Fonti e riferimenti

• NIST SP 800-218 SSDF
• OWASP SAMM
• OWASP ASVS
• OWASP Code Review Guide
• SLSA