CI/CD controlli minimi per app AI

Quando un team usa coding agent, Copilot, Codex, Cursor, Claude Code o strumenti simili, il collo di bottiglia non è più solo scrivere codice: diventa decidere cosa può entrare in main senza portare in produzione segreti, dipendenze fragili, test deboli, configurazioni permissive o modifiche non comprese.

La pipeline CI/CD deve diventare un freno intelligente: non deve bloccare ogni esperimento, ma deve impedire che una pull request generata o modificata con AI superi merge e deploy senza evidenze minime. Per DevOps, developer e CTO, il punto operativo è questo: se l’AI accelera il diff, la pipeline deve rendere più chiaro il rischio prima che quel diff diventi release.

Perché la pipeline è il punto di controllo naturale

Una review umana può perdersi in una PR grande, uno scanner può produrre rumore e un test funzionale può passare anche se l’autorizzazione è fragile. La pipeline serve a mettere ordine: stabilisce quali controlli sono obbligatori, quali finding bloccano il merge, chi può approvare una deroga e quali evidenze restano dopo il rilascio.

Con codice AI-generated questo diventa ancora più importante, perché l’agente può aggiornare codice, test, lockfile, Dockerfile, workflow, variabili ambiente, IaC e script di deploy nella stessa modifica. Se la pipeline controlla solo che “la build sia verde”, lascia passare proprio i rischi più costosi.

Build success non significa release readiness. Una build riuscita dice che il software si compila o che i test previsti passano, ma non dice che i segreti sono al sicuro, che le dipendenze sono accettabili, che le policy cloud sono strette, che i test coprono casi di abuso o che l’artifact prodotto è tracciabile.

Proteggere main prima di aggiungere scanner

Il primo controllo CI/CD non è uno scanner: è impedire merge diretti e bypass non governati. main deve richiedere pull request, review, controlli obbligatori e ownership chiara sulle aree sensibili. Le modifiche generate da AI vanno trattate come qualunque altra modifica, ma con attenzione a tre segnali: diff troppo ampio, file sensibili toccati insieme a codice funzionale, test aggiornati dallo stesso agente che ha scritto la feature.

Controlli minimi da applicare:

Branch protection su main.
Required checks non disattivabili dal singolo developer.
CODEOWNERS o reviewer obbligatori per auth, ruoli, API, pipeline, IaC e segreti.
Blocco del merge se la PR modifica workflow CI/CD senza review dedicata.
Policy esplicita per deroghe e hotfix.

Test: non solo happy path generati dall’AI

Gli agenti sono bravi a scrivere test che confermano il comportamento implementato, ma spesso coprono solo il percorso felice: utente corretto, ruolo corretto, input corretto, stato corretto. Per una pipeline utile servono invece test negativi derivati dal rischio: utente senza permessi, tenant diverso, token scaduto, input manipolato, file non valido, callback contraffatto, idempotenza, rate limit, errore del provider, dati mancanti.

Se una PR tocca autenticazione, autorizzazione, API, pagamenti, dati personali, upload, workflow o logica di business, la pipeline deve richiedere test che provano anche cosa non deve succedere. Un coverage alto non basta se copre solo il comportamento previsto.

SAST con soglie chiare, non come rumore di fondo

Il SAST è utile quando produce decisioni. Se genera centinaia di finding non triati, il team impara a ignorarlo; se non blocca nulla, diventa documentazione decorativa. Per codice generato con AI, il SAST dovrebbe bloccare almeno i nuovi finding critici o ad alta severità su pattern pericolosi: injection, path traversal, deserializzazione, XSS, uso insicuro di crypto, bypass di validazione, secret hardcoded, error handling troppo verboso.

Serve una baseline: i problemi storici non devono paralizzare ogni PR, ma i nuovi problemi introdotti da codice AI-generated devono essere visibili e il risultato deve finire in un flusso di triage con owner, decisione e scadenza.

Dependency scanning e lockfile sotto controllo

Un agente può aggiungere una libreria per chiudere velocemente un task, aggiornare un lockfile o inserire un’action di CI senza valutare manutenzione, licenza, script di installazione, typosquatting o vulnerabilità note. La pipeline deve eseguire Software Composition Analysis su manifest e lockfile, evidenziando le nuove dipendenze introdotte dalla PR. Non tutte le vulnerabilità note devono bloccare subito il merge, ma devono bloccare quelle critiche, sfruttabili e rilevanti per il runtime o per la pipeline.

I cambiamenti a GitHub Actions, GitLab CI, plugin, container base image e tool di build meritano review separata, perché una action non pinnata o un container non controllato può diventare superficie di supply chain anche se il codice applicativo è corretto.

Secret scanning oltre il commit

I segreti non finiscono solo nel codice: possono apparire in .env, history Git, prompt, log CI, output dei test, bundle frontend, source map, container image, artifact, report di scanner o script temporanei generati dall’AI. Per questo il secret scanning deve lavorare su più livelli — pre-commit se possibile, push protection, repository history, pipeline log, artifact e container — perché se una credenziale è finita in un contesto leggibile, non basta rimuoverla dal file: va ruotata e va verificato dove è stata usata.

Un buon gate blocca segreti nuovi, maschera output sensibili e limita quali job possono leggere quali variabili. Uno scanner che gira nello stesso job dei token di produzione eredita un rischio inutile.

IaC, container e configurazioni: i file collaterali non sono collaterali

Per far passare una demo, un agente può cambiare CORS, security header, Dockerfile, Terraform, Helm chart, workflow, variabili ambiente, bucket, IAM, deploy script o permessi cloud. Queste modifiche sembrano accessorie, ma possono aprire la superficie reale, quindi la pipeline deve includere IaC scanning, container scanning e policy-as-code dove il perimetro lo richiede. Soprattutto, i file di deploy non devono essere approvati solo da chi ha chiesto la feature.

Esempi di blocco ragionevole: bucket pubblico non previsto, wildcard IAM, secret in env plain text, continue-on-error su job di security, debug mode in produzione, immagini base vulnerabili, deploy su produzione senza environment approval.

Artifact, SBOM e tracciabilità della build

Quando una release va male, il team deve sapere quale commit, quale workflow, quali dipendenze e quale artifact sono arrivati in produzione. Con AI coding questa tracciabilità è ancora più importante, perché il diff può essere stato prodotto in modo rapido e distribuito su molti file. Il livello minimo è collegare PR, commit, build, artifact e deploy; per perimetri più maturi entrano SBOM, firma degli artifact, provenance e attestazioni.

Non serve introdurre tutto subito, ma serve evitare build non riproducibili, artifact sovrascritti e deploy manuali non tracciati. Una pipeline che produce evidenze aiuta anche la remediation: sapere quale versione contiene una dipendenza vulnerabile, quale container è stato pubblicato e quali ambienti sono stati aggiornati riduce tempi e ambiguità.

Deploy gate, rollback e remediation

Il controllo pre-merge non basta: staging e produzione devono avere gate diversi, perché una modifica può essere accettabile in staging e non in produzione quando cambia dati reali, utenti, costi, SLA o compliance. Prima del deploy in produzione servono almeno controlli passati, approvazione dell’ambiente, smoke test, verifica configurazioni, piano di rollback e owner della release. Per app esposte, può servire anche DAST mirato o test manuale sui flussi critici.

Il rollback non deve essere improvvisato quando qualcosa va male. Se la pipeline pubblica artifact immutabili e conserva migrazioni, versioni e configurazioni, tornare indietro è un’operazione gestibile. Se ogni deploy è un insieme di passi manuali, la velocità dell’AI aumenta solo la probabilità di perdere controllo.

Checklist CI/CD per codice generato con AI

Proteggi main con PR obbligatorie, required checks e reviewer owner.
Blocca merge diretto e bypass non tracciati.
Richiedi test negativi per auth, ruoli, tenant, API, input e flussi critici.
Esegui SAST con blocco sui nuovi finding critici o ad alta severità.
Esegui SCA su manifest, lockfile, action/plugin e container base image.
Esegui secret scanning su commit, history, log, artifact e container quando applicabile.
Scansiona IaC, Dockerfile, workflow e configurazioni cloud.
Richiedi review dedicata per CI/CD, IAM, deploy, segreti e ambienti.
Collega commit, build, artifact, SBOM o evidenze equivalenti.
Definisci deploy gate diversi per staging e produzione.
Prepara il rollback e verifica che sia eseguibile.
Collega i finding a owner, SLA e verifica di remediation.

Quando coinvolgere ISGroup

Una pipeline interna può bastare per progetti piccoli e modifiche isolate. Serve una verifica più strutturata quando l’AI coding entra nel flusso ordinario di sviluppo, quando più team lavorano su repository condivisi, quando le PR toccano auth, dati, API, cloud o pipeline, oppure quando i finding restano aperti senza una gestione ricorrente.

Scenario	Rischio principale	Controllo consigliato
Uso continuativo di coding agent nel ciclo di sviluppo	Gate disomogenei e controlli non ripetibili	Software Assurance Lifecycle
Finding ricorrenti da SAST, SCA, secret scanning o VA	Vulnerabilità non prioritizzate o non chiuse	Vulnerability Management Service
PR AI-generated su auth, API, segreti, dipendenze o business logic	Vulnerabilità o regressioni nel codice	Code Review
App o API già esposte online	Comportamento abusabile dall’esterno	Web Application Penetration Testing
Cloud, IaC, IAM, container o pipeline di deploy	Misconfiguration e privilegi eccessivi	Cloud Security Assessment

Il punto non è aggiungere strumenti a caso, ma definire quali controlli bloccano il merge, quali producono alert, quali richiedono review umana e quali entrano in un ciclo di remediation.

Evidenze da preparare

Per una verifica efficace servono repository, workflow CI/CD, branch protection, elenco dei required checks, policy di review, esempi di PR generate da AI, report SAST/SCA/secret scanning, gestione dei segreti, ambienti, artifact, container, IaC, log di build, strategia di deploy e rollback. Servono anche decisioni documentate: quali finding bloccano, quali possono essere accettati, chi approva le deroghe, quali SLA di remediation esistono e come si verifica che il problema non ricompaia nella release successiva.

Domande frequenti

Una pipeline verde basta per fidarsi del codice generato con AI?
No. Basta solo se la pipeline include controlli adeguati al rischio: test negativi, SAST, SCA, secret scanning, IaC e container scanning, review obbligatorie, deploy gate e remediation tracciata.
Quali controlli devono bloccare il merge?
Segreti nuovi, finding critici introdotti dalla PR, dipendenze critiche sfruttabili, test mancanti su aree sensibili, modifiche non revisionate a pipeline, IAM o deploy, e configurazioni che espongono dati o ambienti.
Gli auto-fix generati dall’AI sono sicuri?
Vanno trattati come altro codice AI-generated. Possono correggere un finding, ma anche cambiare logica, test, dipendenze o configurazioni, quindi serve review sul diff prodotto dall’auto-fix.
Quando serve il Software Assurance Lifecycle?
Quando l’AI coding non è più un esperimento individuale ma parte del ciclo di sviluppo: più team, più repository, release frequenti, policy di review, gate e remediation ricorrente.
Quando serve il Vulnerability Management Service?
Quando i finding devono essere gestiti nel tempo: prioritizzazione, owner, SLA, verifica del fix, report e controllo che le vulnerabilità non restino aperte o ricompaiano.

Se stai adottando coding agent e vuoi evitare che la velocità di sviluppo si traduca direttamente in rischio di produzione, ISGroup può aiutarti a definire gate CI/CD, review obbligatorie e remediation ricorrente per codice generato o modificato con AI.

Vuoi un Software Assurance Lifecycle realmente sicuro, continuo e conforme?

Affidati a ISGroup per:

Code review manuale e test reali in ogni fase dello sviluppo
Integrazione con DevSecOps, SBOM e remediation assistita
Compliance completa a NIS2, GDPR, DORA con supporto tecnico dedicato

Parla con un esperto

CI/CD per codice generato con AI: controlli minimi prima del merge in main