La sicurezza del software riguarda sempre più l’intera software supply chain e non soltanto il codice che si sviluppa. Librerie open source, dipendenze, immagini container e pacchetti di terze parti contribuiscono a ciò che viene eseguito in produzione. Per questo serve conoscere la composizione degli artefatti software, la loro provenienza, le licenze utilizzate e i controlli superati prima del rilascio. È necessario poter dimostrare che questi controlli sono coerenti, applicati in modo sistematico e supportati da evidenze verificabili.
In questo articolo vediamo il ruolo del DevSecOps, il motivo per cui l’attenzione si è spostata sull’artefatto e i primi passi per costruire una governance efficace.
DevSecOps è un modello che integra i controlli di sicurezza nel ciclo di sviluppo e rilascio del software. Invece di essere concentrati in un’unica verifica finale prima della messa in produzione i controlli vengono eseguiti durante la fase di build, nei repository e nelle pipeline CI/CD.
Il concetto non è nuovo e il paradigma DevSecOps è ormai consolidato. Lo abbiamo approfondito anche parlando di software open source e DevSecOps come binomio possibile.
Ciò che è cambiato è il contesto in cui viene applicato e il tipo di interlocutori coinvolti. Fino a qualche anno fa, la richiesta di introdurre controlli automatici nelle pipeline proveniva soprattutto dai team di ingegneria. Oggi arriva sempre più spesso dall’esterno dell’organizzazione. I clienti enterprise, ad esempio, la inseriscono nei processi di qualifica dei fornitori, le funzioni di risk management nella raccolta delle dipendenze critiche, le funzioni legali e di procurement nella verifica dei requisiti di sicurezza, licenza e conformità. La sicurezza della software supply chain ha quindi smesso di essere soltanto un indicatore di maturità tecnica diventando un vero e proprio requisito commerciale.
Ci sono quattro domande a cui un’organizzazione dovrebbe saper rispondere per misurare il livello di maturità del proprio approccio DevSecOps e della propria capacità di governare la software supply chain. La prima riguarda la composizione del software. Il cliente vuole conoscere i componenti di terze parti inclusi nella fornitura, insieme alle relative versioni e licenze. Non si parla soltanto del codice sviluppato internamente, occorre considerare anche librerie, pacchetti, immagini container, runtime e dipendenze transitive.
La seconda domanda riguarda la provenienza dei componenti. È necessario poter ricostruire la fonte, il registry, il processo di acquisizione e la catena di build. Dire che un componente proviene da un repository pubblico non è sufficiente. È importante sapere quale versione è stata utilizzata, da quale fonte è stata prelevata e attraverso quale processo è entrata nella build.
La terza domanda riguarda, invece, l’autorizzazione al rilascio. Ogni artefatto dovrebbe arrivare in produzione dopo aver superato una serie di controlli definiti in anticipo. Questo significa sapere quale policy è stata applicata, quali verifiche sono state eseguite e come sono state gestite eventuali eccezioni.
E, infine, l’ultima domanda riguarda la capacità di reagire alle vulnerabilità. Quando viene segnalato un problema critico in una libreria ampiamente utilizzata, l’azienda deve poter sapere rapidamente quali applicazioni utilizzano quel componente e quali versioni sono presenti negli ambienti di sviluppo e produzione.
È questo il perimetro della software supply chain security, che comprende la conoscenza, la protezione e la gestione di ogni componente utilizzato per realizzare il software.
In un’applicazione, il codice sviluppato internamente costituisce spesso una parte minoritaria di ciò che viene eseguito. Il resto comprende librerie open source, dipendenze, immagini, runtime e componenti prodotti o gestiti da soggetti terzi. L’unità che arriva in produzione non è quindi il singolo commit, è l’artefatto, che può essere un JAR, un’immagine container, un pacchetto o un altro oggetto pronto per il rilascio, insieme a tutte le sue dipendenze.
Per questo conviene concentrare una parte importante dei controlli sull’artefatto.
Ad esempio, l’analisi statica del codice sorgente resta fondamentale per individuare difetti di implementazione e problemi legati alla qualità. È anche il motivo per cui utilizziamo SonarQube nelle pipeline dei nostri clienti.
Per rispondere alle domande sulla composizione, sulla provenienza e sull’autorizzazione al rilascio, però, è necessario intervenire nel punto in cui gli artefatti vengono archiviati, verificati e promossi tra gli ambienti. Questo punto è il repository. Qui è possibile conoscere la composizione di ogni pacchetto, associare un artefatto alla relativa build e applicare policy di sicurezza e conformità. Il repository consente inoltre di bloccare la promozione quando una regola non viene rispettata e di ricostruire rapidamente la composizione di una release.
Nelle pipeline che governiamo per clienti dei settori energy, telco e financial services, questo rappresenta uno dei punti di controllo più efficaci. Se gestito correttamente, il repository permette di rispondere a gran parte delle domande sulla composizione e sulla provenienza del software.
Abbiamo approfondito questo approccio nella guida dedicata a repository e sicurezza degli artefatti con JFrog Artifactory.
Quando si parla di sicurezza, l’attenzione si concentra sul costo potenziale di un incidente. È un aspetto importante, ma non sempre è il parametro più utile per decidere da dove iniziare, perché si tratta di un evento ipotetico e difficile da stimare con precisione. I costi della mancata governance emergono invece nella gestione quotidiana e riguardano i tempi di risposta a un problema, gli accordi commerciali e la fiducia nell’efficacia dei controlli.
In assenza di una governance strutturata, la stessa attività può richiedere giorni di lavoro, proprio mentre il comitato di crisi attende le informazioni necessarie per decidere come intervenire. Con un sistema centralizzato, invece,l’azienda può individuare rapidamente i servizi coinvolti. È un costo immediato, misurabile e destinato a ripresentarsi a ogni nuovo allarme.
Una risposta incompleta durante una qualifica fornitore non comporta necessariamente la perdita immediata del contratto. Più spesso rallenta il processo, introduce condizioni aggiuntive o richiede nuove verifiche.
Il risultato è un ciclo di vendita più lungo, soprattutto nelle trattative enterprise in cui sicurezza, compliance e gestione del rischio sono parte integrante della valutazione.
Se uno strumento genera centinaia di segnalazioni indistinte, senza priorità chiare e senza un processo per gestire falsi positivi ed eccezioni, il team finirà per ignorarle. Il controllo rimarrà formalmente attivo, ma perderà efficacia operativa. La presenza di report e indicatori può così creare un’apparenza di sicurezza senza riflettere la situazione reale. È il motivo per cui, nella nostra esperienza, la definizione delle policy e la gestione delle eccezioni sono spesso più importanti dell’introduzione di un ulteriore strumento.
L’obiettivo è integrare pratiche DevSecOps per applicare policy di sicurezza in fase di rilascio.
La sicurezza degli artefatti non richiede necessariamente un programma pluriennale. Nella maggior parte dei casi consiste nell’introdurre un livello di controllo all’interno di attività che i team svolgono già ogni giorno.
Le dipendenze vengono scaricate, le applicazioni vengono compilate e gli artefatti vengono promossi tra gli ambienti. Il lavoro consiste nell’inserire controlli in questi flussi senza creare processi separati, come le 5 pratiche DevSecOps da integrare nei flussi CI/CD.
Un primo percorso può essere articolato in un trimestre e snodarsi in quattro fasi.
La prima fase consiste nel costruire un inventario affidabile nelle prime tre settimane. È necessario capire quanti repository di artefatti esistono realmente in azienda, chi li amministra e quali pipeline li alimentano. Il risultato del censimento è spesso più articolato di quanto previsto dal management. Proprio per questo, l’inventario rappresenta una base essenziale per definire le priorità.
Dalla quarta alla sesta settimana ha luogo la fase 2 nella quale si può scegliere la pipeline più critica per il business e utilizzarla come punto di partenza. Su questo flusso viene attivata la scansione automatica degli artefatti il cui obiettivo è raccogliere dati reali sulla composizione, sulle vulnerabilità, sulle licenze e sulla provenienza dei componenti.
Il passo successivo avviene dalla settima alla nona settimana e consiste nel definire una prima policy di sicurezza. La policy deve indicare con chiarezza quali condizioni impediscono la promozione di un artefatto e come devono essere gestite le eccezioni. Deve inoltre identificare le persone responsabili della valutazione e dell’autorizzazione. Una policy che non produce mai conseguenze operative è soltanto un report. Per verificare l’efficacia del controllo è necessario accettare un certo livello di attrito e usarlo per migliorare il processo.
L’ultima fase consiste nella scelta di una metrica semplice e comprensibile anche al di fuori del team tecnico.
Un esempio è il tempo necessario per identificare quali servizi in produzione contengono un determinato componente. Misurare questo dato prima e dopo l’introduzione del controllo permette di dimostrare il valore del percorso con un indicatore concreto.
Dopo il primo trimestre, il modello può essere esteso ad altre pipeline, policy e livelli più avanzati di tracciabilità.
Per chi desidera un riferimento indipendente dai vendor, framework aperti come il Supply-chain Levels for Software Artifacts (SLSA) offrono un modello per descrivere e migliorare i livelli di integrità della catena di build senza vincolare l’azienda a uno specifico prodotto.
DevSecOps è un modello che integra i controlli di sicurezza nel ciclo di sviluppo e rilascio del software. I controlli vengono inseriti nelle fasi di build, nei repository e nelle pipeline CI/CD. L’obiettivo è individuare vulnerabilità, problemi di licenza e non conformità prima che correggerli possa diventare complesso e dispendioso in termini di risorse umane ed economiche.
Una parte significativa di ciò che viene eseguito in produzione è costituita da componenti che non sono stati sviluppati internamente. Tra questi rientrano librerie, immagini container, runtime e dipendenze transitive. L’artefatto è l’unità effettivamente rilasciata. Controllarlo significa verificare non solo il codice proprietario, ma anche tutto ciò che l’applicazione incorpora.
Non necessariamente. I controlli sono più efficaci quando vengono integrati nelle pipeline già utilizzate dai team di sviluppo, senza creare processi paralleli. È però indispensabile definire responsabilità chiare. Occorre stabilire chi definisce le policy, chi valuta i rischi e chi autorizza eventuali eccezioni.
Un trimestre può essere sufficiente per passare da una visibilità limitata a un punto di controllo attivo su una pipeline critica, con una prima policy e una metrica misurabile. L’estensione alle altre pipeline può avvenire in modo progressivo, senza interrompere i flussi esistenti.
Se vuoi capire qual è il livello di maturità della tua software supply chain e quale controllo potrebbe generare il maggiore impatto sulla tua pipeline, contattaci.