Secure coding ISO 27001 (A.8.28) quando il codice lo scrivono gli agenti AI: le prove che l'auditor vuole vedere

Che cosa chiede il controllo A.8.28 della ISO 27001?

Il controllo 8.28 della ISO/IEC 27001:2022, Secure coding, chiede di applicare principi di codifica sicura allo sviluppo del software. È nato con l'edizione 2022. La sua guida nella ISO/IEC 27002:2022 procede in tre fasi, pianificazione prima di scrivere codice, scrittura, verifica e manutenzione, e va oltre il tuo codice fino ai componenti di terze parti e open source.

L'ente di certificazione DQS ha presentato il nuovo controllo a gennaio 2023, in un articolo del suo auditor Markus Jegelka: il quadro «is to be applied holistically both to the company's own program code and to software from third parties and open source sources», va cioè applicato nel suo insieme sia al codice dell'azienda sia al software di terze parti e open source. Oggi un auditor lavora solo sull'edizione 2022: la transizione dalla precedente si è chiusa il 31 ottobre 2025, e quel giorno sono scaduti i certificati emessi sulla vecchia edizione, come ricorda l'ente di certificazione irlandese NSAI, che cita il documento obbligatorio MD 26 dell'IAF.

Un auditor legge l'8.28 insieme ai controlli di sviluppo che gli stanno intorno, e quando il codice lo scrivono gli agenti ciascuno di questi diventa una domanda molto concreta:

I titoli sono quelli dell'Annex A del 2022, lasciati nella loro forma inglese. ISO vende i testi delle sue norme, quindi le formulazioni citate in questa guida vengono da enti di certificazione e società di consulenza che le riportano.

La ISO 27001 dice qualcosa sugli agenti di coding AI?

La ISO 27001 non dice nulla sugli agenti di coding AI. L'edizione 2022, uscita a ottobre 2022 ed emendata una sola volta secondo il catalogo ISO, non ha nessun controllo dell'Annex A sull'AI. Il codice che un agente scrive nel tuo repository con un account che gli hai dato tu è codice tuo, soggetto agli stessi controlli di sviluppo.

È una risposta che delude chi si aspetta una clausola apposita, ed è anche la più utile. La guida dell'8.28 chiede già di tenere fuori dal codice le pratiche insicure, fra cui le password scritte direttamente nel codice e i frammenti di codice non approvati, come riassume ISMS.online a proposito della ISO 27002. Un agente che copia uno schema da un altro punto del repository, o dal proprio addestramento, produce esattamente questo, un frammento di codice non approvato, e lo produce più in fretta di quanto un revisore riesca a leggerlo riga per riga. Il controllo è stato scritto per il codice di qualunque provenienza, e gli agenti sono semplicemente una provenienza in più.

Quando un team adotta gli agenti saltano fuori altre due domande, ed entrambe stanno fuori dall'8.28. Che cosa manda l'agente al provider del modello, e quel provider è valutato come fornitore? Le nostre guide su che cosa Claude Code invia ad Anthropic e su che cosa conserva Cursor rispondono alla prima domanda, strumento per strumento. E se qualcuno ti chiede se ti serve la ISO/IEC 42001, la norma sui sistemi di gestione dell'AI che ISO ha pubblicato a dicembre 2023 per le organizzazioni «providing or utilizing AI-based products or services», cioè che forniscono o usano prodotti o servizi basati sull'AI, la risposta è che si tratta di una certificazione separata, e la ISO 27001 non la richiede.

Quali prove chiede l'auditor quando il codice lo scrivono gli agenti?

L'auditor chiede tre tipi di prove: documenti che dicono come sviluppi in modo sicuro, configurazioni che mostrano che i tuoi controlli sono imposti, e registrazioni che dimostrano che hanno girato sulle modifiche del periodo di audit. Con gli agenti, i documenti devono nominarli, e le registrazioni devono coprire ogni modifica andata in merge, comprese quelle che nessuna persona ha scritto.

La società di consulenza Advisera riassume il test dell'8.28 in una riga, nella sua pagina sul controllo: l'auditor verifica «if principles for secure coding are integrated into the software lifecycle process», cioè se i principi di secure coding sono integrati nel ciclo di vita del software, e se non li trova «this is considered a nonconformity», è una non conformità. I documenti in sé «are not mandatory, but are recommended», non sono obbligatori ma sono raccomandati: una Secure Development Policy in un'azienda piccola o media, una Secure Coding Policy in una più grande. Nella pratica l'auditor fa poche domande e campiona delle modifiche per verificare le risposte:

Sui test serve un avvertimento a parte. Quando l'agente scrive la funzionalità e i relativi test nella stessa sessione, una suite tutta verde dimostra che il codice fa quello che l'agente ha capito. Nello studio controllato di CybeDefend, almeno un terzo delle deviazioni dalle regole che l'agente ha lasciato nel codice era coperto dai suoi stessi test, che passavano, quindi la CI non le avrebbe mai segnalate. È un test di sicurezza che l'agente non ha scritto, una scansione o un controllo della tua CI, a dare un senso all'8.29.

Un CLAUDE.md o un AGENTS.md vale come prova di secure coding?

Un file di regole non è una prova: è una policy che l'agente legge all'inizio della sessione, e nulla al suo interno registra se il codice l'ha rispettata. Nello studio controllato di CybeDefend del 24 agosto 2026, una sezione di regole realistica ha lasciato tante regole violate per ticket quante nessun file, 2,27 contro 2,28.

I team che preparano un audit lavorando con gli agenti mettono spesso il proprio standard di secure coding nel CLAUDE.md o nell'AGENTS.md, ed è un posto sensato perché l'agente lo trovi. La stessa documentazione di Anthropic sulla memoria ne fissa il limite: Claude tratta questi file «as context, not enforced configuration», come contesto e non come configurazione imposta, e «there's no guarantee of strict compliance», non c'è alcuna garanzia che vengano rispettati alla lettera. Il nostro studio ha misurato che cosa significa sui ticket veri. Un solo agente, Claude Opus 5, ha lavorato trenta ticket di sviluppo in tre configurazioni, novanta run valutate alla cieca su griglie sigillate. Con una sezione di regole tenuta a mano, l'agente ha implementato alla lettera 7 dettagli di regola su 55, lo stesso punteggio ottenuto senza alcun file. Con l'intero corpus delle regole incollato parola per parola nel file, è arrivato a 7 su 11. I dettagli sono nel nostro articolo su se Claude Code segue davvero il CLAUDE.md.

Per un auditor è la differenza fra il disegno di un controllo e il suo funzionamento. Il file mostra che hai messo lo standard per iscritto e che l'hai consegnato all'agente, e questo ti aiuta sull'8.25 e sull'8.28. Del codice che ne è uscito, invece, non mostra nulla. Nello stesso studio è andata meglio servire ogni regola nel momento in cui l'agente scrive la riga, con 0,28 regole violate per ticket, ed è quello che fa VibeDefend. Anche così, quello che l'auditor accetta come prova è il controllo che ha girato sulla modifica e la traccia che ha lasciato.

Come dimostri quale codice ha scritto un agente?

Lo mostra la tua cronologia git, se i tuoi agenti ci lasciano una traccia. Di default Claude Code aggiunge a ogni commit un trailer Co-Authored-By con il nome del modello, e basta un'impostazione per toglierlo. Il 27 ottobre 2026, 467 dei 494 commit degli ultimi 90 giorni sul branch principale del repository del nostro sito portavano quel trailer.

Per contarli abbiamo lanciato due comandi su quel repository:

git log origin/main --since=2026-07-29 --no-merges --format=%H | wc -l
git log origin/main --since=2026-07-29 --no-merges -i --grep="Co-Authored-By: Claude" --format=%H | wc -l

Nell'arco del periodo i trailer nominano cinque modelli Claude diversi, quindi la cronologia dice quale modello ha scritto quale modifica, mentre gli altri 27 commit non hanno alcun trailer. Il riferimento delle impostazioni spiega da dove arriva: di default Claude Code aggiunge Co-Authored-By: <name> <noreply@anthropic.com>, dove il nome è quello del modello in uso, e impostare attribution a false lo nasconde. Una traccia che ogni sviluppatore può spegnere è una convenzione, non un controllo. Se vuoi che entri fra le tue prove, fissala nelle managed settings che la tua organizzazione distribuisce, e verifica che cosa lasciano gli altri tuoi agenti nei commit e nelle pull request, perché ogni strumento si comporta in modo diverso.

Sapere chi ha scritto una modifica dice all'auditor quali modifiche guardare, mentre il controllo vero e proprio è l'insieme dei gate da cui passa ogni modifica. Il nostro articolo sulla revisione delle pull request scritte da un agente AI spiega perché un account macchina dedicato, con commit firmati, vale più di un'etichetta che chi contribuisce può dimenticare di mettere.

SOC 2 chiede la stessa cosa?

SOC 2 chiede quasi la stessa cosa, con due criteri. Il CC8.1 vuole modifiche al software autorizzate, progettate, sviluppate, documentate, testate, approvate e implementate. Il CC7.1 vuole rilevamento e monitoraggio che intercettino nuove vulnerabilità, con le scansioni di vulnerabilità fra i suoi points of focus. Un report Type II verifica poi che questi controlli abbiano funzionato nel periodo.

I Trust Services Criteria dell'AICPA stanno dietro un login sul sito dell'AICPA, quindi il testo qui sotto è quello riportato nella documentazione di Wazuh. CC8.1: «The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.» CC7.1: «To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.» In sostanza, ogni modifica passa da autorizzazione, test e approvazione, e l'organizzazione deve accorgersi sia delle configurazioni che aprono una vulnerabilità sia delle vulnerabilità appena scoperte. Fra i points of focus elencati sotto i due criteri, il CC8.1 comprende «Tests System Changes» e «Approves System Changes», e il CC7.1 comprende «Conducts Vulnerability Scans».

La differenza con la ISO 27001 sta nella forma del risultato. La ISO certifica un sistema di gestione, con i controlli dell'Annex A che hai selezionato nella tua Dichiarazione di Applicabilità. SOC 2 è invece un report di attestazione. Nelle parole della società di audit TrustNet, «A licensed CPA gives an opinion on whether your controls are properly designed (Type I) and, if applicable, effectively operating over time (Type II)»: un revisore abilitato si esprime sul disegno dei controlli e, nel Type II, sul loro funzionamento nel tempo. Con gli agenti, un periodo Type II significa registrazioni per ogni modifica lungo diversi mesi, e l'auditor le campiona come farebbe un auditor ISO. Un team pronto per l'uno è vicino a essere pronto anche per l'altro.

Che cosa devi avere pronto prima dell'audit?

Ti servono una policy di sviluppo sicuro che nomini i tuoi agenti, uno standard di codifica sicura, una scansione su ogni modifica dietro un gate che rifiuta i finding critici, un registro delle eccezioni con approvatori e scadenze, pull request testate e approvate e un report che copra il periodo di audit, tutto aggiornato al giorno in cui l'auditor campiona.

1. La policy nomina gli agenti. Quali agenti, con quali account, su quali repository, e che cosa l'agente non può fare da solo, per esempio il merge o il deployment.
2. Lo standard è breve e verificabile. Elenca che cosa vieti e indica il controllo che trova ciascun punto. Una regola che nessun controllo può trovare è una regola che solo un revisore può far rispettare.
3. Ogni modifica riceve la stessa scansione. Codice, dipendenze, segreti e file di infrastruttura, su ogni pull request, che l'abbia aperta una persona o un agente.
4. Il gate decide, e registra. Un finding critico blocca il merge; un rischio più basso genera un avviso e la modifica passa. Ogni eccezione ha un perimetro, una data, una motivazione e l'approvazione di una persona con nome e cognome.
5. Approvazione e test restano con la modifica. La pull request porta con sé l'approvazione, l'esecuzione della CI e il risultato della scansione, così una modifica campionata si spiega da sola.
6. Il report copre il periodo. Un unico documento che l'auditor può leggere, costruito a partire dalle scansioni e non incollato da un foglio di calcolo.

Ticket con i requisitiL'agente scrive la modificaScansione sulla modificaIl gate blocca o avvisaApprovata e testataNel report

I punti 3, 4 e 6 sono quello che produce la piattaforma AppSec di CybeDefend. Su ogni repository analizza le debolezze del codice (SAST), le dipendenze (SCA), i segreti, l'infrastructure as code, i container e le pipeline CI/CD. Una policy di sicurezza scritta come codice blocca il merge su un finding critico e avvisa sui rischi minori, a livello di organizzazione, di team e di progetto, e un'eccezione è limitata a un percorso, datata, motivata e approvata da una persona con nome e cognome, e ognuna lascia una riga di audit. I report di sicurezza mappano i finding sull'OWASP Top 10 e sulla CWE Top 25, per organizzazione, team o progetto, ed escono in PDF per l'auditor, in HTML o in JSON per uno strumento GRC. Se stai preparando la ISO 27001 o SOC 2 con un team che sviluppa con gli agenti, possiamo ripercorrere tutto insieme. Per il quadro più ampio di che cosa cambia quando il codice lo scrivono gli agenti, parti dalla nostra guida alla sicurezza degli agenti di coding AI.

Domande frequenti

Con la ISO 27001 si possono usare gli agenti AI per scrivere codice?

Sì. Nella ISO/IEC 27001:2022 non c'è nulla che li vieti, e nessun controllo del suo Annex A riguarda l'AI. Il codice che un agente scrive nel tuo repository è codice tuo, quindi i controlli dall'8.25 all'8.29 e l'8.32 si applicano a lui come al codice digitato da uno sviluppatore. La tua policy deve dire quali agenti sono ammessi e come vengono controllate le loro modifiche.

Si può escludere il controllo 8.28 dalla Dichiarazione di Applicabilità?

Se sviluppi software, in pratica no. La ISO 27001 ti permette di escludere un controllo dell'Annex A, ma la clausola 6.1.3 d) chiede di motivare l'esclusione nella Dichiarazione di Applicabilità, ed escludere il secure coding mentre scrivi codice è difficile da difendere. Un auditor che non trova principi di codifica sicura nel tuo processo di sviluppo registra una non conformità.

Per la ISO 27001 serve una secure coding policy?

Non come documento obbligatorio. Una secure coding policy fissa i principi di codifica che seguono i tuoi sviluppatori e i tuoi agenti, e il modo in cui li verifichi. La ISO 27001 non la impone, ma gli auditor si aspettano di trovare quei principi da qualche parte: in una Secure Development Policy in un'azienda piccola o media, in una Secure Coding Policy separata in una più grande.

All'audit ISO 27001 basta mostrare il CLAUDE.md o l'AGENTS.md?

No. Il file mostra che hai dato all'agente il tuo standard, non che il codice lo rispetta. Anthropic scrive che Claude tratta questi file come contesto e non come configurazione imposta, e nello studio di CybeDefend del 24 agosto 2026 un file di regole realistico ha lasciato 2,27 regole violate per ticket, contro 2,28 senza file. L'auditor vuole le registrazioni dei controlli che hanno girato su ogni modifica.

Ogni modifica scritta da un agente AI deve passare da una revisione umana?

L'auditor si aspetta che ogni modifica sia approvata prima del rilascio: approvare le modifiche di sistema è uno dei points of focus del CC8.1 di SOC 2, e l'8.32 della ISO 27001 copre la gestione delle modifiche. È la tua policy a decidere come vengono approvate le modifiche degli agenti, e l'auditor verifica che le pull request campionate corrispondano a quello che la policy dice.

Per usare gli agenti AI serve anche la ISO 42001?

No. La ISO/IEC 42001:2023 è una norma separata, dedicata ai sistemi di gestione dell'AI, che ISO ha pensato per le organizzazioni che forniscono o usano prodotti o servizi basati sull'AI. La ISO 27001 non la richiede, e il tuo auditor 27001 valuta l'uso che fai degli agenti attraverso i controlli della 27001.

SOC 2 richiede le scansioni delle vulnerabilità?

Il criterio CC7.1 chiede rilevamento e monitoraggio che identifichino nuove vulnerabilità, e «Conducts Vulnerability Scans» è uno dei suoi points of focus. I criteri non nominano alcuno strumento. L'auditor verifica i controlli che hai descritto e, in un report Type II, li verifica sull'intero periodo.

Come si traccia il codice scritto da un agente AI?

Usa quello che i tuoi agenti scrivono in git. Di default Claude Code aggiunge a ogni commit un trailer Co-Authored-By con il nome del modello, e l'impostazione attribution può toglierlo, quindi bloccala nelle managed settings. Un account macchina dedicato con commit firmati è una prova più solida. Sapere chi ha scritto il codice dà all'auditor il perimetro; le prove sono i controlli su ogni modifica.