Quante volte abbiamo sentito parlare di DevSecOps e SecDevOps? Spesso utilizzati impropriamente come sinonimi nascondono invece una differenza sostanziale. Per capirla basata notare la posizione del termine “Sec” nella parola.
DevSecOps presenta la sequenza “Dev”, “Sec” e “Ops” e si riferisce ad una modalità con la quale prima viene effettuato lo sviluppo di un software (Dev), poi sono presi in considerazione gli aspetti di Sicurezza (Sec) e infine l’Operation (Ops).
SecDevOps prevede invece la sicurezza “Sec” all’inizio della pipeline ancor prima dello sviluppo (Dev). Adottando questo approccio gli aspetti di sicurezza dalle politiche, linee guida, standard di sviluppo, requisiti di sicurezza saranno integrati in tutto il ciclo di vita del software. Inoltre, questa modalità si trasforma in un circolo virtuoso riuscendo a formare naturalmente tutto il team sul ruolo e gli aspetti di security. Infatti, mentre nell’approccio DevSecOps il team di Sviluppo continuerà a creare il software indipendentemente dai requisiti di sicurezza nel SecDevOps dovrà adottarli fin dall’inizio acquisendo nel tempo competenze e sensibilità sulla materia.
È necessario sottolineare inoltre l’effort richiesto nei due approcci. Nel primo, DevSecOps, la security viene considerata quasi come un layer aggiuntivo da prendere in considerazione solo a software definito. Implementare i requisiti di sicurezza in questa fase potrebbe risultare molto oneroso, meno efficace o di difficile implementazione. Non a caso spesso si ripiega sull’assunzione del rischio preferendo mandare in esercizio un sistema seppur non completamente sicuro pur di rispettare il time to market.
Un corretto approccio anche in linea con gli ultimi standard, normative e direttive internazionali è il SecDevOps. Ma come metterlo in campo? Quale può essere un corretto approccio?
Il principio base è considerare la sicurezza nelle primissime fasi di definizione di un nuovo software alla stregua degli obiettivi e requisiti di business e non come layer aggiuntivo. Questo richiede un cambiamento culturale dell’azienda e nei modelli organizzativi e procedurali condividendo la responsabilità della sicurezza tra tutti i team.
È sicuramente utile automatizzare le attività e adottare strumenti di testing in tutte le fasi dello sviluppo. Sono disponibili numerose tecnologie a disposizione degli sviluppatori per rilevare i difetti di sicurezza prima che vengano integrati in una versione finale del software. Tra questi troviamo le tecnologie tradizionali SAST e DAST o le più recenti IAST e RASP che vanno a sopperire le difficoltà delle prime in merito nella gestione di librerie e dei framework presenti nelle app moderne. Ognuno di questi tool potrebbe essere utilizzato in diverse fasi del ciclo di vita del software.
La tecnologia SAST (Static Application Security Testing), in modalità “white box”, consente di identificare le vulnerabilità di sicurezza presenti nel codice sorgente già nelle prime fasi del ciclo di vita dello sviluppo senza la necessità di eseguire il codice sottostante. La risoluzione delle vulnerabilità inoltre è meno onerosa e più veloce. È tuttavia un’analisi statica, non può riconoscere le vulnerabilità del codice in esecuzione che rileva invece la tecnologia DAST (Dynamic Application Security Testing). DAST inserendo degli errori in un’applicazione in esecuzione, in genere app web, identifica vulnerabilità e bug comuni (es. SQL injection e cross-site scripting) e mette in risalto i problemi di runtime non identificabili da un’analisi statica.
Elementi delle tecnologie SAST e DAST tra loro complementari sono integrati nella tecnologia IAST (Interactive Application Security Testing) producendo risultati più accurati verificando una gamma più ampia di regole di sicurezza rispetto a SAST o DAST. Pensati per essere eseguiti nell’application server, come agent non richiedono l’istallazione di plug-in né la modifica di applicazioni o attività di penetration test. L’analisi viene condotta dall’interno dell’applicazione attraverso l’inserimento di funzionalità in determinati punti dell’esecuzione dell’applicazione. Le tecnologie IASR rilevano, infatti, in tempo reale problemi di sicurezza analizzando il traffico e il flusso di esecuzione delle applicazioni. Non è necessario modificare le applicazioni, né condurre specifiche attività di penetration testing.
Di recente adozione è anche la tecnologia RASP (Run-time Application Security Protection) uno strumento di test che consente a un’app di eseguire controlli di sicurezza continui su sé stessa e di rispondere agli attacchi in tempo reale terminando la sessione di un utente malintenzionato e avvisando i difensori dell’attacco.
È importante sottolineare che pur rispondendo ad una serie di carenze delle SAST e DAST, le nuove tecnologie IAST e RASP possono avere un effetto negativo sulle prestazioni delle applicazioni.
Una tecnologia abbastanza recente e molto utile per proteggere la catena di fornitura del software è, invece, la tecnologia SCA (Software Composition Analysis). La SCA non effettua l’analisi statica e dinamica del software ma verifica le librerie, i framework e i componenti di terze parti utilizzati all’interno della tua applicazione, un aspetto assolutamente da non sottovalutare!
Sono numerosi ormai gli incidenti di sicurezza causati da prodotti di terze parti non adeguatamente verificati sui quali sono state sfruttate vulnerabilità applicative e/o aggiunte componenti malevole.
Considerare le terze parti non è più un optional ma un requisito minimo. Non a caso sono in fase di sviluppo diversi framework in questo ambito. Tra tutti ricordiamo SLSA[1] (Supply chain Levels for Software Artifacts) il framework di Google volto a proteggere la pipeline di sviluppo e distribuzione del software end-to-end e mitigare le minacce in ogni anello della sua catena.
La soluzione si ispira all'”Autorizzazione binaria per Borg” interna di Google e si basa su due principi fondamentali la non unilateralità, ovvero nessuno può modificare l’artefatto software in qualsiasi punto della catena di fornitura del software senza un’esplicita revisione e approvazione da parte di almeno un’altra “persona di fiducia” e la verificabilità, ovvero l’artefatto software può essere ricondotto in modo sicuro e trasparente alle origini e alle dipendenze originali leggibili dall’uomo. Lo scopo principale è l’analisi automatizzata di fonti e dipendenze, nonché indagini ad hoc.
SLSA include al suo interno serie di standard, strumenti per automatizzare la creazione di metadati per l’auditing, un processo di accreditamento per certificarne la conformità agli standard e controlli tecnici (ancora in woking progress).
Il framework presenta anche un approccio a quattro livelli di protezione SLSA.[2] Più il livello è alto maggiore sarà la protezione dagli attacchi. Ad oggi livello corrispondono delle garanzie di integrità incrementali. Dal livello SLSA1 che richiede il processo di compilazione completamente automatizzato e che generi la provenienza, al livello SLSA4 che oltre a includere tutti i livelli precedenti aggiunge requisiti ancora più stringenti quali sono la revisione obbligatoria di tutte le modifiche da parte di due diversi sviluppatori.
Non parliamo quindi di un semplice elenco di regole e best practice. Come affermato da Kim Lewandowski del Google Open Source Security Team e Mark Lodato del Binary Authorization for Borg Team “In its final form, SLSA will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give “SLSA certification” to a particular package or build platform”.
Di seguito alcuni esempi di attacchi che si possono verificare in ogni anello della catena di fornitura e una tabella su come SLSA può essere utile [3].
| Threat | Known example | How SLSA could have helped | |
| A | Submit bad code to the source repository | Linux hypocrite commits: Researcher attempted to intentionally introduce vulnerabilities into the Linux kernel via patches on the mailing list. | Two-person review caught most, but not all, of the vulnerabilities. |
| B | Compromise source control platform | PHP: Attacker compromised PHP’s self-hosted git server and injected two malicious commits. | A better-protected source code platform would have been a much harder target for the attackers. |
| C | Build with official process but from code not matching source control | Webmin: Attacker modified the build infrastructure to use source files not matching source control. | A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering. |
| D | Compromise build platform | SolarWinds: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build. | Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence. |
| E | Use bad dependency (i.e. A-H, recursively) | event-stream: Attacker added an innocuous dependency and then updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (i.e. attack F). | Applying SLSA recursively to all dependencies would have prevented this particular vector, because the provenance would have indicated that it either wasn’t built from a proper builder or that the source did not come from GitHub. |
| F | Upload an artifact that was not built by the CI/CD system | CodeCov: Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly. | Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo. |
| G | Compromise package repository | Attacks on Package Mirrors: Researcher ran mirrors for several popular package repositories, which could have been used to serve malicious packages. | Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo. |
| H | Trick consumer into using bad package | Browserify typosquatting: Attacker uploaded a malicious package with a similar name as the original. | SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions. |
In conclusione, prima le organizzazioni introdurranno il modello SecDevOps e prima riusciranno a fronteggiare lo scenario di minacce e ad essere competitive sul mercato. Non sarà una transizione immediata ma graduale. Il primo passo sarà dunque indurre un cambiamento culturale e organizzativo distribuendo le responsabilità della security e innescando un circolo virtuoso di formazione. Sarà indispensabile comprendere e considerare ogni tipologia di software e componente utilizzata nell’organizzazione così come adottare gli strumenti di testing in tutte le fasi del ciclo di vita del software. Un’attenzione particolare dovrà essere risposta alla gestione dei rischi legati alle terze parti, negli ultimi anni molto sottovalutata.
[1] https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html
[2] https://github.com/slsa-framework/slsa
[3] https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html
Autrice: Elena Agresti
