DevSecOps: cos'è e come funziona in pratica

DevSecOps è il modo di sviluppare, rilasciare e gestire il software in cui la sicurezza fa parte del lavoro di tutti i giorni, invece di essere un controllo finale. Sviluppo (Dev), sicurezza (Sec) e operations (Ops) condividono la responsabilità: i controlli girano dentro la pipeline CI/CD a ogni modifica del codice, e il monitoraggio continua dopo il rilascio.

Qui trovi la definizione del NIST, cosa cambia rispetto al DevOps, quali controlli entrano in ogni fase, perché anche la pipeline va messa in sicurezza e cosa c'entrano NIS2, Cyber Resilience Act e ISO 27001.

DevSecOps: la definizione

Il NIST, nella Special Publication 800-204C del marzo 2022, descrive il DevSecOps come una cultura e un insieme di pratiche, sostenute da strumenti automatici, che aumentano collaborazione, fiducia e responsabilità condivisa fra chi consegna il software: sviluppo, operations e sicurezza. Secondo lo stesso documento, gli elementi che lo reggono sono tre:

• le pipeline CI/CD (integrazione continua, consegna o rilascio continuo), che portano il codice dallo sviluppatore alla produzione passando per build, test, pacchettizzazione e rilascio;
• i test di sicurezza lungo tutto il ciclo di vita, non solo prima del rilascio;
• il monitoraggio continuo a runtime, cioè mentre l'applicazione è in produzione.

Il NIST riconosce anche che sul termine non c'è un consenso unanime: una parte della comunità continua a dire DevOps e considera la sicurezza già compresa. La parola DevSecOps è nata per sottolineare che la sicurezza va verificata e integrata in ogni fase, dalla build all'esercizio.

DevOps e DevSecOps: cosa cambia

Il DevOps ha tolto la separazione fra chi scrive il software e chi lo gestisce in produzione, e ha portato i rilasci da pochi grandi aggiornamenti a modifiche piccole e frequenti. In molte aziende la sicurezza è rimasta fuori da quel cambio: una revisione o un penetration test a fine progetto, con tempi che non reggono rilasci settimanali o giornalieri.

Il DevSecOps porta i controlli dentro il flusso. In pratica cambiano tre cose:

1. Quando si controlla: a ogni modifica, nella pipeline, invece che una volta prima del rilascio. È quello che spesso si chiama shift left, spostare i controlli verso l'inizio del ciclo, quando lo sviluppatore ha ancora il codice davanti.
2. Chi controlla: lo sviluppatore riceve il risultato nel suo strumento di lavoro, mentre il team di sicurezza definisce le regole e gestisce le eccezioni invece di fare ogni verifica a mano.
3. Come si organizza il lavoro: il NIST indica come fattore critico di successo un gruppo trasversale, con sviluppatori, specialisti di sicurezza ed esperti di operations, per ogni parte dell'applicazione.

I controlli lungo la pipeline

Un riferimento pubblico e gratuito per decidere cosa controllare è il Secure Software Development Framework del NIST (SP 800-218, versione 1.1 del febbraio 2022, con una revisione in bozza dal dicembre 2025). Non nomina prodotti e, come dice il documento stesso, si integra in qualsiasi modello di sviluppo, DevOps compreso. Divide le pratiche in quattro gruppi: preparare l'organizzazione (PO), mettere al sicuro il software (PS), produrre software con il minimo di vulnerabilità (PW), rispondere alle vulnerabilità (RV). In una pipeline diventano controlli in punti precisi.

Mentre si scrive il codice

• Analisi statica (SAST) nell'IDE e a ogni build, con una persona che rivede le segnalazioni: è l'esempio che il NIST fa nella pratica PW.7.2.
• Scansione dei segreti: chiavi, token e password non devono entrare nel repository. Come toglierli dal codice lo spieghiamo nella guida al secrets management.
• Revisione delle modifiche: per la pratica PS.1.1 il codice sta in un repository con accesso al minimo privilegio, ogni modifica è tracciata sull'account di chi l'ha fatta e il responsabile del codice approva le modifiche degli altri.

Quando entrano le librerie di terze parti

La software composition analysis (SCA) confronta le dipendenze, comprese quelle indirette, con le vulnerabilità note. Il NIST, nella pratica PW.4.1, indica fra gli esempi di raccogliere informazioni sulla provenienza di ogni componente, per esempio con la SBOM (la distinta base del software) o con la stessa analisi della composizione, e di usarle per valutare il rischio che il componente porta. Cos'è una SBOM e cosa contiene lo trovi nell'approfondimento sulla SBOM.

Quando si costruisce e si rilascia

• Test dinamici (DAST) sull'applicazione in esecuzione, inseriti nella suite di test automatici del progetto: è uno degli esempi della pratica PW.8.2. Le differenze fra i tre tipi di test sono nel confronto SAST, DAST e SCA.
• Integrità degli artefatti: firma dei commit e del codice eseguibile, hash crittografici sui file (PS.1.1). Servono a dimostrare che quello che arriva in produzione è quello che è uscito dalla build.
• Infrastruttura come codice: Terraform, CloudFormation, manifest Kubernetes. Il NIST 800-204C distingue cinque tipi di codice in un'applicazione cloud native (applicazione, servizi applicativi, infrastruttura, policy, osservabilità) e prevede che ognuno possa avere la sua pipeline.

Dopo il rilascio

Il ciclo non si chiude con il deploy. Il gruppo RV dell'SSDF chiede di individuare e confermare le vulnerabilità dopo il rilascio (RV.1), valutarle e correggerle in ordine di priorità (RV.2) e cercarne le cause di fondo (RV.3), così che lo stesso errore non torni al rilascio successivo. Il monitoraggio a runtime, terzo elemento della definizione NIST, alimenta questo ciclo.

La pipeline è anche un bersaglio

Una pipeline CI/CD ha accesso al codice, alle chiavi dei cloud e alla produzione. OWASP ha dedicato un progetto ai suoi rischi specifici, la Top 10 CI/CD Security Risks. Tre dei dieci si incontrano presto anche in un team piccolo:

• Controlli di flusso insufficienti (CICD-SEC-1): chi ottiene accesso al repository o al sistema di CI riesce da solo a spingere codice o artefatti verso la produzione, perché manca un'approvazione o una revisione obbligatoria. Fra gli esempi OWASP cita le regole che uniscono in automatico le pull request.
• Poisoned Pipeline Execution (CICD-SEC-4): un attaccante con accesso al solo repository, senza accesso all'ambiente di build, modifica la configurazione della pipeline e fa eseguire i suoi comandi durante la build. Sono più esposte le pipeline che partono da pull request o da commit su branch qualsiasi, perché eseguono codice che nessuno ha ancora rivisto.
• Igiene delle credenziali insufficiente (CICD-SEC-6): segreti e token sparsi nella pipeline, con controlli d'accesso deboli o permessi troppo ampi, che un attaccante può raccogliere e usare.

Le contromisure stanno anche nell'SSDF, pratica PO.5.1: ambienti di sviluppo separati fra loro e dalla produzione, autenticazione a più fattori per ogni ambiente, accesso umano diretto ai sistemi di build ridotto al minimo, monitoraggio di ogni accesso privilegiato.

Le persone contano più degli strumenti

Uno scanner che produce centinaia di segnalazioni che nessuno legge non cambia il software che va in produzione. Per questo l'SSDF mette l'organizzazione prima della tecnica:

• ruoli e formazione (PO.2): chi fa cosa nella sicurezza del software, con formazione specifica per ruolo;
• criteri misurabili (PO.4.1): fra gli esempi, aggiungere i criteri di sicurezza alla Definition of Done del team agile e registrare approvazioni, rifiuti ed eccezioni nel sistema di tracciamento;
• security champion: la pratica PW.1.1 cita la formazione del team di sviluppo, e dei security champion in particolare, per l'analisi del rischio. Sono le persone che fanno da riferimento per la sicurezza dentro il proprio team.

DevSecOps e cloud

Nel cloud il confine fra codice e infrastruttura si assottiglia: il template Terraform è codice, l'immagine del container è un artefatto della pipeline, il ruolo IAM sta in un file di configurazione. E un difetto nel codice pesa in modo diverso a seconda di dove gira: una libreria vulnerabile in un servizio esposto su internet con accesso ai dati dei clienti non è lo stesso rischio della stessa libreria in un servizio interno senza accessi rilevanti.

Collegare il difetto al contesto è il lavoro delle piattaforme CNAPP, che si sono estese verso la pipeline. Wiz, di cui siamo partner, lo fa con Wiz Code. Secondo la pagina del prodotto, controlla l'infrastruttura come codice, cerca i segreti scritti nel codice, nei template e nelle immagini dei container, rileva le vulnerabilità nelle dipendenze dirette e transitive, verifica la configurazione dei sistemi di versionamento e di CI/CD e propone le correzioni nell'IDE, nelle pull request o nella pipeline. La mappatura dal cloud al codice riporta un rischio trovato in produzione al sorgente che l'ha generato.

Cosa c'entrano NIS2, Cyber Resilience Act e ISO 27001

Nessuna di queste norme usa la parola DevSecOps. Tutte e tre chiedono però cose che, per chi sviluppa software, si dimostrano con una pipeline costruita così.

• NIS2: l'art. 24, comma 2, del D.Lgs. 138/2024 elenca fra gli elementi minimi delle misure di sicurezza la lettera e), "sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità", e alla lettera d) la sicurezza della catena di approvvigionamento. Il comma 3 aggiunge che, nel valutare i fornitori, i soggetti tengono conto delle loro pratiche di sicurezza, "comprese le loro procedure di sviluppo sicuro". Per una software house che lavora per un soggetto NIS2, il processo di sviluppo entra nella valutazione del cliente.
• Cyber Resilience Act: il regolamento (UE) 2024/2847, allegato I, parte II, chiede ai fabbricanti di prodotti con elementi digitali di identificare e documentare vulnerabilità e componenti, anche con una SBOM, di correggere tempestivamente le vulnerabilità e di effettuare "prove e riesami efficaci e periodici della sicurezza del prodotto con elementi digitali". I requisiti dell'allegato I si applicano dall'11 dicembre 2027 (art. 71); gli obblighi di segnalazione dell'art. 14 valgono già dall'11 settembre 2026.
• ISO/IEC 27001:2022: nell'Annex A i controlli 8.25 (ciclo di vita dello sviluppo sicuro), 8.28 (codifica sicura), 8.29 (test di sicurezza in sviluppo e accettazione) e 8.31 (separazione degli ambienti di sviluppo, test e produzione) riguardano proprio questo. In audit, i risultati dei controlli nella pipeline con le correzioni tracciate sono l'evidenza più diretta.

Da dove partire

Per un'azienda mid-market con applicazioni proprie e un team di sviluppo di poche persone, un ordine ragionevole è questo:

1. Fai l'inventario: repository, pipeline, chi ha accesso e con quali permessi, quali segreti usano.
2. Chiudi la pipeline: revisione obbligatoria prima del merge sui branch principali, autenticazione a più fattori, nessun codice non rivisto eseguito con accesso a credenziali di produzione.
3. Togli i segreti dal codice e attiva la scansione prima del commit.
4. Introduci la SCA: si attiva in fretta e copre il codice che nessuno in azienda ha scritto.
5. Aggiungi SAST e scansione dell'infrastruttura come codice, partendo dalle regole con meno falsi positivi e allargando quando il team ha preso il ritmo.
6. Scrivi i criteri: cosa blocca un rilascio, chi approva un'eccezione, dove si registra. È la parte che regge in audit.

Se il tuo software gira sul cloud, il passo successivo è vedere cosa arriva davvero in produzione e cosa raggiunge una volta lì. Con la fotografia del cloud colleghiamo Wiz ai tuoi account via API, senza agenti, e ti mostriamo cosa è esposto e in che ordine sistemarlo.