La sicurezza delle applicazioni aziendali non si risolve con un test prima del rilascio. Il DevSecOps permette di integrare controlli e responsabilità lungo tutto il ciclo di sviluppo, riducendo il rischio di scoprire vulnerabilità quando intervenire è già complesso.

Gestionali, portali, sistemi per ordini e contratti: le Business Application custodiscono molti dei dati più importanti di un’azienda. Una vulnerabilità può quindi avere conseguenze che vanno oltre il funzionamento del software: accessi non autorizzati, esposizione di dati, interruzioni operative e interventi urgenti su applicazioni già utilizzate dal business.

Il problema diventa particolarmente evidente quando la sicurezza entra nel progetto troppo tardi. Immaginiamo che un penetration test, eseguito a due settimane dal go-live, rilevi una vulnerabilità nelle autorizzazioni. Un utente potrebbe consultare documenti appartenenti a un’altra azienda cliente. Correggere il problema non significa necessariamente modificare poche righe di codice: potrebbe richiedere di rivedere la gestione degli accessi, intervenire sulle API e ripetere parte dei test. Nel frattempo, il rilascio è già pianificato.

Il DevSecOps serve a evitare scenari come questo: integra la sicurezza nel lavoro quotidiano di chi progetta, sviluppa e gestisce il software.

Che cos’è il DevSecOps

DevSecOps nasce dall’integrazione di Development, Security e Operations. L’obiettivo è considerare la sicurezza durante l’intero ciclo di vita del software, dalla raccolta dei requisiti alla gestione dell’applicazione in produzione.

Questo approccio viene spesso associato allo shift left, cioè all’anticipazione delle verifiche. Se un problema viene individuato durante la progettazione o lo sviluppo, è generalmente più semplice intervenire rispetto a quando l’applicazione è già in esercizio. 

Ma anticipare i controlli non basta. Dopo il rilascio possono emergere nuove vulnerabilità nelle librerie utilizzate, cambiare le configurazioni o diventare necessari nuovi requisiti di sicurezza. Serve quindi mantenere un collegamento tra chi sviluppa il software e chi lo gestisce.

Il NIST Secure Software Development Framework (SSDF, SP 800-218) segue la stessa impostazione: le pratiche di sviluppo sicuro vanno inserite nel ciclo di vita adottato dall’organizzazione, non gestite come attività separate.

Il DevSecOps non garantisce un software privo di vulnerabilità. Aiuta piuttosto a individuare prima i problemi, gestire quelli che emergono successivamente e rendere più chiaro chi deve intervenire.

Perché correggere tardi è più complicato

Un problema di sicurezza può nascere da un requisito non definito, da una scelta architetturale, da una dipendenza vulnerabile, da un’autorizzazione implementata male o da una configurazione non coerente tra ambienti. Se una regola di accesso viene definita durante l’analisi, entra nell’architettura e nei test fin dall’inizio. Se la stessa carenza emerge dopo il rilascio, può essere necessario modificare più componenti, rieseguire i test, verificare i dati coinvolti e pianificare una release correttiva, mentre l’applicazione è già in uso.

Secondo il Verizon Data Breach Investigations Report 2026, lo sfruttamento di vulnerabilità è il vettore di accesso iniziale più frequente nelle violazioni analizzate, con una quota del 31% contro il 20% dell’edizione precedente. Il rapporto segnala anche che le correzioni procedono più lentamente: per le vulnerabilità incluse nel catalogo CISA Known Exploited Vulnerabilities il tempo mediano di correzione completa è passato da 32 a 43 giorni, e solo il 26% di esse è stato corretto del tutto (38% l’anno precedente).

Questi numeri riguardano vulnerabilità note di prodotti diffusi, non difetti del codice scritto su misura, quindi non misurano direttamente le Business Application. Mostrano però che anche quando il problema è noto e già sfruttato, la correzione richiede settimane. Chi scopre un difetto a rilascio avvenuto deve analizzarlo, correggerlo, testarlo e rilasciarlo mentre l’applicazione è in uso.

Quando la vulnerabilità ha già provocato un incidente, si aggiungono le attività di analisi, contenimento, comunicazione e gestione degli eventuali obblighi normativi o contrattuali.

Le fasi di un ciclo di sviluppo sicuro

Non esiste una pipeline adatta a ogni applicazione. I controlli devono essere proporzionati ai dati trattati, all’esposizione, alle integrazioni e alla criticità del processo supportato.

Un ciclo di sviluppo sicuro comprende normalmente alcune attività ricorrenti.

Analisi dei requisiti. Già nella fase iniziale occorre definire quali informazioni gestirà l’applicazione e chi potrà accedervi. Autenticazione, autorizzazioni, logging e conservazione dei dati sono requisiti applicativi da definire insieme alle funzionalità.

Progettazione. Durante la progettazione, il threat modeling aiuta a individuare possibili scenari di attacco e punti deboli dell’architettura. L’attenzione si concentra sui flussi di dati, sulle integrazioni con sistemi esterni, sulle API, sugli account tecnici e sulle autorizzazioni. Framework come OWASP Application Security Verification Standard (ASVS) possono aiutare a trasformare queste analisi in requisiti di sicurezza verificabili. Il NIST SSDF offre invece un riferimento più ampio per organizzare le pratiche di sviluppo sicuro.

Sviluppo. Durante lo sviluppo possono essere automatizzati diversi controlli:

• SAST (Static Application Security Testing): analizza il codice per individuare possibili vulnerabilità.
  
  
• SCA (Software Composition Analysis): identifica le dipendenze software e segnala vulnerabilità note nei componenti utilizzati.
  
  
• Secret scanning: cerca credenziali, token e chiavi che potrebbero essere stati inseriti accidentalmente nei repository.
  
  
• Container e Infrastructure as Code scanning: verifica potenziali problemi nei componenti e nelle configurazioni infrastrutturali.
  
  
• Software Bill of Materials (SBOM): documenta i componenti software utilizzati, facilitandone la tracciabilità e la successiva gestione.

Questi strumenti permettono di intercettare diversi problemi prima che il software venga rilasciato. Restano però necessarie la revisione del codice e le verifiche funzionali di sicurezza, soprattutto quando sono coinvolte regole di business, autorizzazioni e separazione dei dati.

Pensiamo a un portale B2B in cui ogni cliente deve vedere soltanto i propri ordini. Il sistema potrebbe avere un’autenticazione corretta e utilizzare librerie aggiornate, ma presentare un errore nella verifica delle autorizzazioni. Se l’applicazione controlla che l’utente abbia effettuato l’accesso, senza verificare che possa consultare uno specifico ordine, potrebbe esporre informazioni di altri clienti.

Verifica prima del rilascio. Prima della messa in produzione si possono eseguire test dinamici (DAST), verifiche sulle configurazioni e penetration test mirati.

La frequenza dipende dal rischio e dalla natura delle modifiche. Le scansioni automatiche possono essere inserite nel processo di build; un penetration test specialistico richiede invece una pianificazione specifica, per esempio in occasione di modifiche significative o su applicazioni particolarmente critiche.

Le vulnerabilità rilevate devono avere un responsabile e una modalità di gestione definita, perché completare i test non significa aver eliminato i rischi.

Produzione e gestione delle vulnerabilità. La sicurezza di un’applicazione non si esaurisce con il rilascio. Una dipendenza che oggi non presenta vulnerabilità note può risultare vulnerabile in seguito alla scoperta di una nuova falla. Servono quindi:

• inventario aggiornato dei componenti;
  
  
• logging e monitoraggio;
  
  
• processo di vulnerability management, con criteri di priorità e tempi di presa in carico e di correzione;
  
  
• procedura per gli incidenti;
  
  
• comunicazione tra operations, security e sviluppo.
  

Le informazioni raccolte in produzione dovrebbero inoltre tornare ai team di sviluppo, così da intervenire sulle cause dei problemi ed evitare che si ripetano.

Proteggere anche la software supply chain

La sicurezza riguarda anche gli strumenti con cui il software viene costruito e distribuito.

Repository, sistemi di build, account di servizio, registry e dipendenze esterne fanno parte della software supply chain. Se uno di questi elementi viene compromesso, il rischio può propagarsi all’applicazione anche senza una modifica diretta al codice sviluppato internamente.

È quindi necessario controllare gli accessi ai repository e alle pipeline, proteggere le credenziali, verificare le dipendenze e limitare chi può modificare i processi di rilascio.

Quando il contesto lo richiede, si possono aggiungere controlli sull’integrità e sulla provenienza degli artefatti software, per aumentare la fiducia nel processo con cui vengono generati e distribuiti.

Come evitare che la sicurezza rallenti lo sviluppo

Uno dei dubbi più frequenti riguarda l’impatto del DevSecOps sui tempi di delivery.

Introdurre controlli aggiuntivi richiede attività di configurazione, manutenzione e gestione delle segnalazioni. Inoltre, non tutte le vulnerabilità individuate hanno la stessa criticità: uno scanner potrebbe generare falsi positivi o segnalare problemi che non risultano effettivamente sfruttabili nel contesto applicativo. Bloccare ogni rilascio in presenza di qualsiasi segnalazione può rendere il processo ingestibile. Ignorarle per rispettare le scadenze porta al rischio opposto.

La soluzione è definire criteri condivisi di valutazione. Una vulnerabilità nota, già sfruttata attivamente e presente in un componente esposto su Internet, può richiedere un intervento immediato. Una vulnerabilità non raggiungibile nel contesto dell’applicazione potrebbe invece essere gestita con tempi diversi, dopo un’adeguata verifica.

Per le eccezioni servono una motivazione documentata, un responsabile, una scadenza e l’accettazione del rischio residuo da parte di chi ne ha l’autorità. Con criteri condivisi il team sa cosa bloccare, cosa pianificare e cosa accettare, e ogni decisione lascia una traccia.

DevSecOps e conformità normativa

Integrare controlli e criteri di sicurezza nel ciclo di sviluppo può aiutare a gestire in modo più strutturato alcuni requisiti del quadro normativo europeo, e lascia evidenze utili: report delle scansioni, tempi di correzione, eccezioni approvate. Non costituisce però, di per sé, una certificazione né una garanzia di conformità.

Il GDPR, all’articolo 25, prevede il principio di protezione dei dati personali fin dalla progettazione e per impostazione predefinita. Per le applicazioni che trattano dati personali, integrare requisiti di sicurezza e privacy nella progettazione può aiutare il titolare del trattamento ad attuare misure adeguate.

Per i soggetti essenziali e importanti, l’articolo 24 del D.Lgs. 138/2024, che recepisce la NIS2 in Italia, comprende tra le misure di gestione del rischio la sicurezza nell’acquisizione, nello sviluppo e nella manutenzione dei sistemi, inclusa la gestione e divulgazione delle vulnerabilità, nonchè la sicurezza della catena di approvvigionamento. L’art. 23 prevede inoltre che gli organi di amministrazione e direttivi approvino le modalità di attuazione di queste misure, sovrintendano all’implementazione e rispondano delle violazioni del decreto, oltre a seguire una formazione periodica. Chi decide budget e priorità di un progetto software ha quindi un interesse diretto a sapere come viene gestita la sicurezza.

Per i fornitori di sviluppo e integrazione applicativa, le misure sulla catena di approvvigionamento (art. 24, comma 2, lett. d) possono tradursi in richieste di evidenze, requisiti contrattuali e procedure più strutturate per la gestione delle vulnerabilità.

Il Cyber Resilience Act (Regolamento UE 2024/2847) fissa requisiti di cybersicurezza per i prodotti con elementi digitali messi a disposizione sul mercato europeo. Dall’11 settembre 2026 i produttori devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi; la maggior parte degli altri obblighi si applica dall’11 dicembre 2027.

Non tutte le Business Application o i servizi di sviluppo ricadono automaticamente nel perimetro del regolamento: occorre valutare la natura del software e le modalità con cui viene messo a disposizione sul mercato.

DevSecOps nelle applicazioni esistenti: da dove partire

Integrare la sicurezza è più semplice quando i requisiti vengono definiti all’inizio del progetto. Nella realtà aziendale, però, molte applicazioni sono già in produzione, magari da anni, e utilizzano architetture, componenti e processi di rilascio differenti.

Non è sempre necessario riprogettare tutto: un primo intervento può consistere nell’analizzare le dipendenze software, verificare come vengono gestite le credenziali o introdurre controlli automatici in una pipeline già esistente. In altri casi la priorità potrebbe essere la revisione delle autorizzazioni o la mappatura delle API esposte.

Per scegliere da dove iniziare è utile rispondere ad alcune domande:

• Quali applicazioni supportano i processi aziendali più critici e quali dati gestiscono?
  
  
• Chi è responsabile dei requisiti di sicurezza e della gestione delle vulnerabilità?
  
  
• Quali controlli vengono già eseguiti durante lo sviluppo e prima di ogni rilascio?
  
  
• Come vengono individuate, valutate e corrette le nuove vulnerabilità dopo il go-live?
  
  
• Quali responsabilità rimangono all’azienda e quali sono affidate al fornitore?

Le risposte consentono di individuare le lacune più rilevanti e pianificare interventi proporzionati. Per verificare se il percorso sta funzionando, si possono monitorare il tempo necessario a correggere le vulnerabilità, la loro distribuzione per criticità ed esposizione, la copertura dei controlli automatici e i problemi che continuano a emergere dopo il rilascio.

L’approccio di Next04

Next04 sviluppa Business Application su misura e affianca allo sviluppo competenze di infrastruttura e cybersecurity: protezione di identità e dati, gestione delle vulnerabilità, supporto alla conformità. Requisiti funzionali, accessi, integrazioni e controlli di sicurezza si decidono quindi insieme. 

Per le aziende che intendono sviluppare una nuova Business Application o intervenire su una soluzione esistente, il punto di partenza è comprendere l’architettura, le integrazioni, i processi di rilascio e i rischi da gestire. Da questa analisi è possibile individuare gli interventi prioritari e valutare come introdurre o rafforzare le pratiche DevSecOps, senza aggiungere complessità non necessarie.

Non occorre necessariamente ripensare l’intero processo di sviluppo. È però importante sapere quali rischi si stanno affrontando, quali controlli sono già presenti e chi deve intervenire quando emerge un problema. Sono questi gli elementi da cui partire per costruire un percorso di miglioramento coerente con le esigenze applicative e operative dell’azienda.