Shift Left Security
Spostare le pratiche di sicurezza all'inizio del ciclo di sviluppo invece che come retrofit a fine processo. Nell'era dello sviluppo AI-assistito il concetto viene riformulato da IBM Technology in 5 principi: non basta "eseguire i security tool prima", bisogna decidere cosa validare, quando, e come costruire fiducia nell'output generato. 1
Perché con l'AI cambia
- Le security practice tradizionali erano pensate per codice scritto da umani e cicli lenti; con l'AI il codice si genera in secondi e non scalano1
- Se la security è solo un retrofit finale, la qualità ne soffre e il processo si blocca; aspettare la fine crea colli di bottiglia e aumenta il rischio
- L'AI non genera solo codice ma introduce anche dipendenze, e produce codice a velocità macchina: lo sviluppatore diventa più responsabile della validazione dell'output 1
I 5 principi (IBM)
- Trust the outcome, not just the generation — il codice AI compila, gira, passa i test di sicurezza ma può nascondere permessi troppo ampi, data leak, fail-open. La domanda non è "funziona?" ma "è sicuro?"
- Security during development — static analysis, pentest, secret scanning, policy check integrati mentre il codice viene creato; bug trovato presto = economico
- Dependency validation — l'AI introduce pacchetti, librerie, servizi: ogni dipendenza aggiunge rischio. Reputazione, vulnerabilità, licenze, supply chain. Non opzionale, parte del secure code generation
- Intent problem — i problemi seri nascono da assunzioni errate, non da codice scadente. Un modello può generare codice elegante e best-practice che però viola le policy perché il requisito era frainteso (analogia re Mida)
- Continuous validation — la domanda non è "ha passato una volta?" ma "continua a passare?". Vulnerability detection, dependency monitoring, patching — anche post-rilascio. "Security is never done"
Esempi concreti dal video: un servizio generato dall'AI recupera correttamente i dati dei clienti, ma dovrebbe davvero avere accesso a tutto il database? Cosa succede se l'autenticazione fallisce, o se dati malformati finiscono nel database e lo corrompono? Un workflow può elaborare correttamente dati finanziari e insieme esporli a utenti che non dovrebbero vederli: è un problema di intent più che di codice. Per la validazione continua IBM suggerisce di usare anche i migliori modelli di frontiera per la vulnerability detection: un modello di frontiera ha di recente trovato una zero-day in un sistema operativo open source rimasta nascosta per 27 anni. 1
Agenti e guardrail
Con AI agentiche che operano multi-step su servizi, repo e pipeline, revisionare singoli file non basta: i problemi peggiori nascono dalle conseguenze non intenzionali tra sistemi connessi. Servono guardrail, identità (accountability), access control e human-in-the-loop. Senza oversight gli agenti diventano risk amplifiers, non productivity tools — vedi Agentic Harness e Coding Agent. 1
Sintesi
"La complessità è il nemico della sicurezza" — la velocità dell'AI crea più codice, più funzionalità, più complessità. La velocità da sola non crea valore, la fiducia sì: avranno successo le organizzazioni che incorporano la security nel flusso quotidiano di sviluppo come continuous validation practice, non come esercizio di compliance o release gate. 1
Vedi anche: Harness Engineering, Pensare in Grande con l'AI, Agentic Harness, Coding Agent, In-Context Learning, Hermes Agent, Sicurezza dei Modelli di Frontiera (i modelli di frontiera che trovano zero-day), e sul lato difensivo delle operations Agentic SOC nella wiki devops