L'integrità delle catene di fornitura del software è diventata un importante punto di discussione negli ultimi anni, con gli attacchi alle catene di fornitura del software che sono diventati più frequenti negli ultimi due anni. È diventato imperativo per gli sviluppatori scegliere con attenzione software e prodotti esterni da includere nei propri sistemi software, adottando allo stesso tempo misure per garantire l'integrità dei propri artefatti software.
Il processo di creazione e distribuzione del software è piuttosto complicato, con molti potenziali punti di vulnerabilità lungo tutta la catena. Invece di fare affidamento su soluzioni specifiche per ciascuna vulnerabilità, è più logico che gli sviluppatori adottino un framework end-to-end più completo che possa aiutare a mitigare le minacce durante la fase di sviluppo.
Uno di questi framework è il Livelli della catena di fornitura per gli artefatti software (SLSA). Questo framework è un elenco di controllo completo di controlli e standard di sicurezza che garantiscono l'integrità dei pacchetti software e dell'infrastruttura.
I SLSA recentemente introdotto quadro di sicurezza è il prodotto di una collaborazione tra OpenSSF., Google e altri soggetti interessati alla sicurezza informatica. Funziona come uno standard di settore concordato che può essere adottato da sviluppatori, aziende e imprese per aiutarli a fare scelte informate sulla sicurezza del software che stanno creando o utilizzando e proteggere l'intero ciclo di vita dello sviluppo del software.
In che modo SLSA aiuta a difendersi dagli attacchi alla catena di fornitura del software
Più che un insieme di regole, il framework di sicurezza SLSA è un framework standard che può potenzialmente rafforzare l’integrità dei componenti di un artefatto software. Questa linea guida end-to-end funge da insieme di misure difensive che impediscono in modo incrementale la manomissione o qualsiasi tipo di modifica non autorizzata ai pacchetti software che compongono un prodotto software. L'adozione del framework SLSA può aiutare a proteggere il software dai virus più comuni attacchi alla catena di approvvigionamento come il seguente:
Attacchi dannosi al repository di commit di PHP
Nel marzo 2021, Nikita Popov ha annunciato che malintenzionati avevano tentato di attaccare il codice sorgente di PHP creando una backdoor che avrebbe consentito loro di ottenere un accesso non autorizzato alla piattaforma del codice. Se avesse avuto successo, l’attacco sarebbe stato devastante, dato che PHP alimenta circa l’80% dei siti web su Internet. Fortunatamente, l’attacco è stato intercettato in tempo, ma questo incidente dimostra comunque come i controlli SLSA possano aiutare a prevenire attacchi simili in futuro. Seguire i protocolli SLSA, come la revisione da parte di due persone e l'autenticazione a due fattori, avrebbe protetto la piattaforma del codice sorgente e l'avrebbe resa un bersaglio molto più difficile per gli aggressori.
Violazione dannosa del compilatore di Apple
Nel 2015, gli sviluppatori di software che creavano app per prodotti Apple hanno scaricato una versione di Xcode (uno strumento di scrittura di codice per dispositivi Apple) da una piattaforma di hosting non verificata. La versione di Xcode conosciuta come XcodeGhost era stata infettata da codice dannoso che veniva segretamente trasferito alle app create con esso. Ha creato una backdoor per diverse app che eludevano il processo di revisione del codice di Apple e le app offerte sull'app store. Il framework SLSA contiene protocolli di sicurezza relativi alla build che avrebbero impedito un attacco come questo o lo avrebbero reso più difficile. Una di queste misure è il requisito di compilazione ermetica che avrebbe costretto gli sviluppatori a dichiarare tutte le loro fonti, incluso lo strumento compilato che hanno utilizzato.
Artefatti dannosi caricati
Il 1° aprile 2021, il team Codecov ha scoperto attacchi che hanno colpito i suoi Bash Uploaders, che includevano Codecov GitHub Action, The Codecov CircleCI Orb e Codecov Bitrise Step. L'aggressore ha ottenuto un accesso non autorizzato estraendo una chiave HMAC che forniva l'accesso all'account del servizio Google Cloud Storage di un livello intermedio di una delle immagini Docker self-hosted pubbliche di Codecov. Questa chiave ha consentito loro di modificare Bash Uploader per caricare codici dannosi direttamente sugli utenti finali. Il framework SLSA avrebbe colto questa azione mostrando quando gli artefatti sono costruiti in modo diverso dalla forma prevista nel loro repository di origine.
Dipendenza errata del flusso di eventi
Nel 2018, gli hacker hanno pubblicato un pacchetto dannoso flatmap-stream su npm e questo è stato successivamente aggiunto come dipendenza al pacchetto event-stream ampiamente utilizzato della piattaforma. Dopo aver aggiunto la dipendenza, gli aggressori l'hanno aggiornata con un comportamento dannoso. Poiché l'aggiornamento non corrispondeva al codice inviato a GitHub, il framework SLSA avrebbe rilevato l'attacco e impedito il vettore. Il monitoraggio della provenienza del codice dannoso avrebbe rivelato che non proveniva da GitHub o dal costruttore corretto. In ogni caso, l’attacco avrebbe potuto essere evitato.
I quattro livelli di sicurezza del quadro di sicurezza informatica SLSA
Il framework SLSA è un protocollo incrementale e utilizzabile. Si compone di quattro livelli, di cui il Livello 4 rappresenta lo stato finale ideale di un sistema protetto. Gli artefatti di altissimo livello soddisfano tutti i requisiti per ottenere la certezza del consumatore che non sono stati manomessi in alcun modo e che tutti i loro componenti possono essere ricondotti alle loro fonti. Gli artefatti ai livelli inferiori sono quelli che hanno raggiunto anche traguardi incrementali con garanzie di integrità specifiche a seconda del loro grado.
Livello 1: gettare le fondamenta
Puoi considerare il Livello 1 del framework SLSA come una sorta di base per l'intero framework per creare software sicuro. In questa fase, gli sviluppatori o le organizzazioni che adottano la SLSA devono fare due cose. Innanzitutto, devono automatizzare completamente il processo di creazione. Questo può essere fatto in diversi modi, ma il modo convenzionale per automatizzare le build è utilizzare un makefile. Anche le azioni GitHub possono essere utilizzate per ottenere gli stessi risultati.
La seconda parte per raggiungere il livello SLSA 1 è generare una documentazione di provenienza completa. Si tratta di metadati che mostrano come è stato creato un artefatto software. Dovrebbe descrivere in dettaglio l'intero processo di compilazione, tutte le dipendenze e le fonti di primo livello utilizzate nella sua creazione.
Scrivere il processo di creazione e mostrare la provenienza di un artefatto software in questo modo rende più semplice per i consumatori prendere decisioni informate sull'utilizzo di un prodotto software. Sebbene la verifica SLSA 1 non significhi che il software sia completamente protetto contro le manomissioni, semplifica l'identificazione dei componenti del software. Questa è la prima fase nella gestione delle vulnerabilità.
Livello 2: assicurati che il processo di creazione sia a prova di manomissione
Il livello 2 del framework SLSA è il punto in cui inizi a mettere in atto misure per garantire che il tuo processo di creazione sia il più resistente possibile alle manomissioni. Il raggiungimento del Livello 2 del quadro SLSA dà inoltre al consumatore maggiore fiducia sull'origine del software.
Ancora una volta, questa operazione viene eseguita in due passaggi: il primo prevede l'utilizzo del controllo della versione e il secondo prevede l'utilizzo di un servizio di compilazione ospitato per autenticare la provenienza. Per il primo passaggio, viene utilizzato GitHub, GitLab o qualsiasi altro servizio simile per archiviare il codice e registrare eventuali modifiche apportate ad esso. Il monitoraggio di eventuali modifiche alla versione in questo modo rende più semplice comprendere eventuali alterazioni eseguite sull'artefatto durante il processo di creazione.
Sebbene il Livello 2 richieda la documentazione sulla provenienza proprio come il Livello 1, la differenza qui è che l'artefatto software deve essere autenticato da un servizio di build ospitato. Il servizio ospitato funge da terza parte fidata che può confermare che il processo di creazione dettagliato nel documento di provenienza iniziale è accurato. GitHub Actions è un tipo di servizio di hosting in grado di fornire una provenienza autenticata.
Livello 3: controlli di sicurezza di SLSA
Il livello 3 è il punto in cui inizi a implementare il controllo di sicurezza specifico come evidenziato nel framework SLSA. Per raggiungere questo livello, l'origine e le piattaforme di creazione degli artefatti software devono soddisfare standard specifici che garantiscano che l'origine sia verificabile e che la provenienza del codice sia attendibile. SLSA Livello 3 fornisce una garanzia molto più forte che l'artefatto sia ben protetto da manomissioni e classi specifiche di minacce.
Alcuni dei requisiti specifici del Livello 3 includono:
- Cronologia e conservazione verificate del codice sorgente—Una cronologia verificata del codice sorgente garantisce che qualsiasi modifica apportata al codice sorgente del software sia accompagnata da un'identità autenticata dell'autore, del revisore o dell'autore del caricamento che ha apportato la modifica con timestamp specifici della modifica. Anche questa cronologia delle modifiche deve essere conservata per almeno 18 mesi.
- Costruzioni isolate in ambienti effimeri—Per soddisfare questo requisito, le build del software devono essere implementate in ambienti temporanei in cui sono completamente indipendenti da qualsiasi altra istanza di build. Per raggiungere questo obiettivo puoi utilizzare un servizio come GitHub Actions, che utilizza una macchina di compilazione virtuale per produrre la tua build su richiesta.
- Compila come codice—Questi criteri richiedono che tu tratti i tuoi file di build come codice. Ciò significa che devono essere archiviati in un sistema di controllo della versione che consenta di ricreare i processi di creazione quando necessario.
- Provenienza non falsificabile—Lo scopo di questo requisito è impedire agli utenti di manomettere la documentazione di provenienza generata dal servizio di compilazione.
Livello 4: fiducia dei consumatori
Il livello 4 del framework SLSA ha lo scopo di garantire che il software non sia stato manomesso in alcun modo. Solo gli artefatti software che hanno soddisfatto i seguenti requisiti possono raggiungere il Livello 4 del framework:
Revisione di tutte le modifiche da parte di due persone
Questo criterio richiede che le organizzazioni incarichino due revisori qualificati per esaminare attentamente qualsiasi modifica proposta al codice e ai componenti del software. Questo processo di revisione da parte di due persone garantisce che solo gli sviluppatori fidati e autenticati possano apportare modifiche agli artefatti software.
Un processo di costruzione ermetico e riproducibile
Un processo di costruzione si dice ermetico quando tutti gli input sono specificati in anticipo e al di fuori del processo di costruzione. Questa regola si applica al codice sorgente nonché a tutti i compilatori, le librerie e gli strumenti utilizzati nella build. Ciò aiuta a garantire l'integrità di tutte le importazioni da terzi. I criteri di costruzione riproducibili non sono un requisito obbligatorio, ma sono anche raccomandati. I criteri richiedono che il processo di compilazione produca lo stesso output indipendentemente da dove o quando viene eseguito.
Requisiti tecnici per soddisfare i livelli SLSA
Il quadro SLSA prevede requisiti tecnici specifici per i diversi livelli. Questi requisiti sono classificati in cinque categorie principali: requisiti di origine, requisiti del processo di creazione, requisiti comuni, requisiti del contenuto di provenienza e requisiti di generazione della provenienza. Ognuna di queste categorie di requisiti è evidenziata di seguito.
Requisiti di origine
Si riferisce ai requisiti che hanno lo scopo di garantire l'integrità del codice sorgente. Il rispetto di questi insiemi di protocolli impedisce manomissioni e modifiche dannose al codice. Garantisce inoltre che eventuali azioni nefaste non passino inosservate. I requisiti relativi alle fonti sono riportati nella tabella seguente.
| Requisiti di origine | Descrizione | Livello SLSA |
| Controllo della versione | Tutte le modifiche al codice sorgente dovrebbero essere tracciate. | 2 |
| Storia verificata | Dovrebbe essere registrata una cronologia completa che dettaglia "chi", "cosa" e "quando" di ogni revisione di versione. | 3 |
| Conservato a tempo indeterminato | Tutte le modifiche alla versione e le informazioni sulla cronologia devono essere archiviate a tempo indeterminato e non devono essere eliminate. | 4 |
| Revisionato da due persone | Due persone fidate e altamente autenticate devono autorizzare qualsiasi modifica di versione. | 4 |
Requisiti di costruzione
Il framework SLSA evidenzia i requisiti di costruzione intesi a migliorare la sicurezza della piattaforma di costruzione e mantenere l'integrità del processo di costruzione.
| Requisiti di costruzione | Descrizione | Livello SLSA |
| Creazione con script | Tutte le fasi del processo di creazione dovrebbero essere completamente automatizzate. | 1 |
| Costruisci servizio | Tutti i passaggi del processo di compilazione devono essere eseguiti su un servizio di compilazione dedicato. | 2 |
| Ambiente effimero e isolato | Il processo di compilazione deve essere eseguito in un ambiente temporaneo fornito appositamente per la compilazione. I passaggi devono essere eseguiti anche in un ambiente isolato, libero da altre istanze di build.
|
3 |
| Senza parametri ed ermetico | Il processo di compilazione dovrebbe basarsi interamente sullo script di compilazione anziché sui parametri utente. Tutti i passaggi di compilazione transitiva dovrebbero essere ermetici, il che significa che tutte le origini e le dipendenze dovrebbero essere completamente dichiarate in anticipo e al di fuori del processo di compilazione. | 4 |
Requisiti per la generazione della provenienza
Questi requisiti hanno lo scopo di verificare l'origine di tutti i componenti di una risorsa software. I requisiti di generazione della provenienza sono evidenziati nella tabella seguente.
| Requisiti per la generazione della provenienza | Descrizione | Livello SLSA |
| Disponibile | Il consumatore dovrebbe avere accesso alle informazioni sulla provenienza in un formato accettabile. | 1 |
| Verificabile | Il consumatore dovrebbe essere in grado di verificare l'autenticità delle informazioni sulla provenienza fornite. | 1 |
| Generato dal servizio | Tutte le informazioni sulla provenienza devono essere generate dal servizio di costruzione.
|
2 |
| Non falsificabile | Gli utenti non possono falsificare i dati di provenienza. | 3 |
| Dipendenze complete | I dati di provenienza dovrebbero includere tutte le dipendenze utilizzate durante le fasi di creazione. | 4 |
Requisiti del contenuto di provenienza
I requisiti del contenuto di provenienza verificano l'identità e l'origine di tutti gli artefatti, le dipendenze e le restrizioni di compilazione utilizzate nel processo di compilazione. Sono evidenziati nella tabella seguente.
| Requisiti del contenuto di provenienza | Descrizione | Livello SLSA |
| Identifica l'artefatto, il costruttore, l'origine e il punto di ingresso. | ● Identifica l'artefatto di output
● Identifica l'entità di compilazione ● Identifica la fonte tramite un riferimento immutabile ● Identifica il comando che ha richiamato lo script di compilazione |
1 |
| Include tutti i parametri di creazione | Tutti i parametri di costruzione dovrebbero essere identificati.
|
3 |
| Include dipendenze transitive e informazioni riproducibili | ● Include tutte le dipendenze transitive
● Se build è riproducibile, devono essere fornite tutte le informazioni necessarie per riprodurla
|
4 |
| Include metadati | Tutti i metadati dovrebbero essere inclusi per facilitare le indagini. | 0 |
Requisiti comuni
I requisiti comuni si applicano agli artefatti software del livello 4 di SLSA. Ci si aspetta che ogni artefatto attendibile soddisfi questi requisiti. Includono requisiti di sicurezza di base e registri che descrivono in dettaglio tutti gli accessi fisici e remoti. I requisiti comuni stabiliscono inoltre un numero limitato di amministratori della piattaforma che possono ignorare le disposizioni contenute nella documentazione SLSA.