Dal caos alla chiarezza: come proteggere la catena di fornitura con le attestazioni

Poiché tutti diventano progressivamente più consapevoli, proteggere le catene di fornitura del software dovrebbe essere una parte vitale della strategia di sicurezza informatica di ogni organizzazione.
Una delle principali difficoltà nella creazione di una strategia globale per mitigare le minacce alla catena di fornitura del software è la complessità e la diversità delle catene di fornitura. Ogni catena di fornitura è unica e gli elementi coinvolti cambiano costantemente, rendendo difficile fidarsi della propria catena di fornitura, per non parlare del software che produce.
In questo articolo descriveremo una piattaforma di conformità continua che consente ai consumatori e ai produttori di software di dimostrare in modo trasparente fiducia e conformità per proteggere l'SDLC, promuovere le migliori pratiche di sicurezza, soddisfare i requisiti normativi e mitigare rischi informatici utilizzando attestazioni.
Il nostro modello proposto è costituito da blocchi impostati che possono essere facilmente estesi e integrati nel tuo stack, indipendentemente dalla piattaforma preferita o dai casi d'uso. Concluderemo dimostrando una politica di verifica di base utilizzando Strumento Valint di Scribe per dimostrare che questo processo non è così complicato come potresti temere a prima vista. 

Teoria del caos della catena di fornitura

Una delle principali sfide nel garantire la sicurezza delle catene di approvvigionamento è l’enorme complessità dei sistemi coinvolti. La tua catena di fornitura del software include ogni parte di software coinvolta nella creazione del tuo prodotto finale, sia come parte dell'ambiente che come parte di software integrata nella tua base di codice. Da questa descrizione si può capire che queste catene di fornitura sono vaste e includono tutto, dal momento in cui uno sviluppatore inizia a scrivere codice attraverso la compilazione, il test, l'integrazione e fino al punto in cui il prodotto finale viene eseguito e incorpora ogni parte di software e libreria utilizzati lungo il percorso.

Definire il modello di sicurezza per tali sistemi richiede la comprensione della vasta gamma di programmi linguaggi, gestori di pacchetti, prodotti, stack tecnologici, servizi CI, fornitori di servizi cloud, importazioni di dipendenze, VM, sistemi operativi e altri componenti che possono essere inclusi in una determinata catena di fornitura. È essenziale considerare l'ampia gamma di risorse che potrebbero essere a rischio all'interno di un sistema di questo tipo, comprese applicazioni, token, chiavi e altre forme di autorizzazioni di accesso.

Panoramica del modello di verifica delle politiche 

Il nostro modello proposto comprende diversi elementi costitutivi che lavorano insieme per garantire la sicurezza e la conformità di una catena di approvvigionamento. Questi elementi costitutivi sono necessari per verificare continuamente gli aspetti di sicurezza del software e la conformità con la regolamentazione della catena di fornitura del software.

• Prova: oggetti immutabili destinati a essere utilizzati automaticamente dalle policy. Questi oggetti contengono metadati necessari per consentire l'applicazione delle policy e soddisfare i requisiti di conformità. Il contenuto delle prove include metadati su artefatti, eventi e impostazioni, ma può anche raccogliere report, configurazioni o scansioni effettivi.
  Prova può presentarsi sia in forma firmata che non firmata. Suggeriamo di seguire la in-toto specifica di attestazione utilizzando il firmato attestazione e non firmato dichiarazione formati, rispettivamente.
  • Attestazioni (prove firmate verificabili AKA): Evidenze verificabili legate a uno specifico contesto ambientale, trasmettendo fiducia utilizzando una qualche forma di firma PKI. 
• Contesto ambientale: Le informazioni contestuali collegano insieme il modello.
  Risponde alla domanda da dove provengono le prove e quali informazioni contengono. È importante che il contesto sia collegato alle prove piuttosto che farne parte, poiché è possibile avere più prove collegate allo stesso contesto e questo modello consente una ricerca e un recupero delle prove più semplice ed efficiente.
  In termini basilari, un contesto ambientale è un sistema di etichettatura in cui la maggior parte delle etichette vengono lette dall'ambiente, dalla piattaforma o dagli artefatti. Le etichette forniscono un accesso normalizzato a molti processi del processo di sviluppo e della pipeline CI/CD. Aspetti legati all'origine delle prove come repository Git, tag e commit, ma anche nomi di flussi di lavoro, nomi di lavori, runID e così via. Il contesto ambientale può includere anche aspetti dell'argomento, come hash, nomi e tag degli artefatti.
  Il contesto può essere visto come un'estensione dell'in-toto Specifica dell'attestazione, integrato nel payload firmato. Utilizzando il sistema di etichettatura, possiamo fornire alla fase di valutazione delle politiche un modo per interrogare le prove mediante etichette in una serie di aspetti. Inoltre, i dati di contesto possono essere utilizzati come parte del processo di valutazione delle politiche, aggiungendo “consapevolezza situazionale” alle prove.

• Politiche: Una serie di moduli di policy configurati dall'utente che definiscono il report di conformità richiesto. Le policy possono specificare gli standard minimi di sicurezza o i livelli di conformità richiesti per diversi tipi di prodotti o sistemi inclusi nella pipeline di creazione o nel processo di sviluppo. Ancora più importante, le valutazioni politiche risultanti creano rapporti di conformità che lo sono attestazioni anche. Questo ci consente non solo di gestire i report di conformità – ad esempio, esponendo il tuo stato di conformità alle parti interessate – ma anche di utilizzare il report di conformità per policy più complesse che possono incapsulare un ambito più ampio di normative di conformità per un'organizzazione. Le politiche possono essere raggruppate in moduli politici. Si tratta di plugin che implementano serie di regole politiche che condividono alcune caratteristiche (simili ai moduli software). Questi plugin sono forniti dai fornitori di policy (ne parleremo più avanti).
  La valutazione di un modulo di policy fornisce risultati che includono valutazioni, dettagli di conformità e verdetti riferiti alla normativa di sicurezza in questione. Inoltre, i risultati includono la traccia storica delle prove necessarie per ricostruire il modulo delle prove valutato per la conformità.
• Negozi: Servizi che forniscono funzionalità di hosting, caricamento/download e interrogazione di prove (ne parleremo più avanti). Possono essere utilizzati su registri di immagini (OCI come archiviazione), servizi dedicati (ad esempio, Scribe Service) o semplicemente sul file system locale.
• Fornitori di politiche: Si tratta di entità (aziende, organizzazioni) responsabili della firma e della fornitura di moduli politici. Fornendo le polizze come una sorta di attestazione, i fornitori trasmettono fiducia e trasparenza alla polizza stessa. Ad esempio, un'attestazione del pacchetto OPA può consentire alle autorità di regolamentazione di pubblicare e firmare pacchetti OPA ufficiali che implementano i moduli politici.

Utilizzando questi elementi costitutivi, il nostro modello consente alle organizzazioni di verificare la sicurezza e la conformità delle proprie pipeline di creazione e del ciclo di vita di sviluppo con relativa facilità.

Come funziona 

Il punto di partenza di questo flusso di lavoro è uno sviluppatore o un sistema, che genera prove per un prodotto o componente software. Il contenuto delle prove, nonché le informazioni contestuali, i soggetti e le firme, vengono raccolti e caricati in un archivio prove.

D'altro canto, i report di conformità vengono creati valutando le politiche adattate alle esigenze e ai requisiti dell'organizzazione.

Utilizzando informazioni contestuali, le valutazioni delle politiche possono interrogare le prove prodotte dalla catena di fornitura e garantire che contengano tutte le informazioni che la regolamentazione potrebbe richiedere.

Come ulteriore vantaggio, le politiche e i report di conformità sono essi stessi accessibili come prove, garantendo trasparenza e fiducia, nonché un percorso storico di tutte le prove coinvolte. Ciò consente alle organizzazioni di gestire i report di conformità ma anche di utilizzarli come attestazioni attendibili per trasmettere fiducia ai consumatori di software.

Utilizzando questo flusso, le organizzazioni e le parti interessate possono ridurre i rischi, fornire trasparenza e garantire la conformità all'interno della propria catena di fornitura, riducendo l'impatto del caos e migliorando la sicurezza generale e la fiducia nei loro prodotti.

Valutazione delle politiche
Il valutazione La definizione di una politica viene effettuata verificando una serie di moduli politici, ciascuno dei quali sostiene normative specifiche ed esigenze di conformità.

Una valutazione politica pone a ciascun modulo due semplici domande:

• Quali prove sono necessarie per conformarsi al modulo?

• Quali sono i criteri per dimostrare la conformità?

Ad esempio, nel contesto del Quadro SLSA (Supply Chain Levels for Software Artifacts)., i moduli delle policy potrebbero specificare che per soddisfare i requisiti di sicurezza sono necessarie prove di provenienza SLSA firmate e una scansione dello stato di sicurezza per la pipeline di compilazione. Le prove fornite da questi moduli verrebbero quindi verificate per garantire che soddisfino tutti i requisiti SLSA.

1. Quali prove sono necessarie per conformarsi ai requisiti SLSA?
   • Un'attestazione di provenienza SLSA (prova firmata) dell'artefatto costruito.
   • Scansione dello stato di sicurezza della pipeline CI che produce l'artefatto.
2. Quali sono i criteri per dimostrare la conformità ai requisiti SLSA?
   • Entrambi gli elementi di prova devono includere informazioni che soddisfano tutti i requisiti SLSA.
     Per questo esempio, l'attestazione di provenienza SLSA deve descrivere il processo di creazione dell'immagine nella sua interezza, mentre l'attestazione del comportamento di sicurezza deve verificare che l'SCM che ha archiviato l'origine dell'immagine utilizzi le regole di protezione del ramo.

Un altro esempio di modulo policy è il Verifica il modulo Artefatto, che specifica che alcuni artefatti devono essere firmati da una fonte attendibile. Utilizzando le attestazioni (prova firmata e verificabile) Firma PKI (Public Key Infrastructure), per soddisfare i requisiti di una persona/entità specifica che deve firmare gli artefatti e oltre ad attestare il contesto da cui hanno avuto origine gli artefatti.
Il Verifica il modulo Artefatto risponde alle seguenti domande:

1. Quali prove sono necessarie per dimostrare la conformità ai requisiti di sicurezza?

• Prova che descrive un artefatto che include una firma PKI (attestazione).

2. Come è possibile verificare queste prove per garantire la conformità?

• La firma PKI dell'attestazione è valida.
• L'identità del certificato PKI corrisponde ai requisiti dell'utente.
• L'oggetto delle prove corrisponde alle esigenze dell'utente.
• Formato e origine corrispondono ai requisiti dell'utente.

Dalla teoria alla pratica 

Esaminiamo l'implementazione di questo modello attualmente supportato dallo strumento Valint.

Diamo un'occhiata a un semplice esempio di policy che specifica come verificare le firme e l'origine di un'immagine.

Nello specifico, dobbiamo verificare che le prove soddisfino i seguenti criteri:

• Il tipo di prova è l'attestazione SBOM CycloneDX che descrive un'immagine.
• Il manufatto è firmato da miaazienda.com.
• L'immagine ha origine da un flusso di lavoro Circle-CI attivato da mia_immagine_src riposo.

Politica sui modelli
Nell'esempio precedente, la policy era statica e controllava solo un'immagine specifica denominata miaazienda/mia_immagine. Tuttavia, spesso è preferibile disporre di policy che supportino funzionalità di modelli/variabili. Ciò consente di definire requisiti che possono essere applicati a più processi o artefatti simili nella pipeline di compilazione CI/CD.

Per modellare la policy, puoi utilizzare una variabile invece di bloccare staticamente la policy su un prodotto. Nell'esempio sopra, puoi modificare il file nome_artefatto valore a `$MY_IMAGE` consentendo invece ai valutatori di configurare un'unica policy per una moltitudine di immagini che richiedono le stesse norme di conformità.

In attesa

At Scriba, il nostro obiettivo finale è mitigare i rischi nella catena di fornitura attraverso un modello di conformità verificabile e basato sull'evidenza. Uno dei primi posti in cui provare questo modello è nella pipeline di compilazione CI/CD. Riteniamo che questo approccio di verifica delle prove sia la chiave per garantire trasparenza e responsabilità nella catena di fornitura, con vantaggi per tutte le parti interessate coinvolte. Il nostro modello incapsula molte delle idee emergenti nella comunità della catena di fornitura del software, definendo la relazione tra molte di esse. Ci impegniamo a innovare e migliorare la trasparenza della catena di fornitura del software. Se questo modello ha suscitato il tuo interesse, ti incoraggio a dare un'occhiata al nostro Documentazione CLI Valint dove espandiamo le capacità e gli usi dello strumento. Sentiti libero di provarlo.

Post Correlati

L'impatto dell'intelligenza artificiale sulla sicurezza della supply chain del software

In un'epoca in cui le minacce informatiche stanno crescendo sia in termini di sofisticatezza che di scala, le organizzazioni si affidano sempre di più all'intelligenza artificiale (IA) per rafforzare i propri framework di sicurezza. Questa tendenza è particolarmente significativa nella sicurezza della supply chain del software, dove l'IA sta diventando uno strumento cruciale per identificare le vulnerabilità, prevedere le minacce emergenti e semplificare lo sviluppo e l'implementazione […]

Utilizzo di SBOM e analisi dei feed per proteggere la catena di fornitura del software

"I fornitori di software devono essere ritenuti responsabili quando non riescono a rispettare il dovere di diligenza nei confronti dei consumatori, delle imprese o dei fornitori di infrastrutture critiche" (la Casa Bianca). Oggi, ci si aspetta che qualsiasi fornitore di software si assuma una maggiore responsabilità nel garantire l’integrità e la sicurezza del software attraverso accordi contrattuali, rilasci e aggiornamenti del software, notifiche e […]

Come evitare il burnout CVE e l'affaticamento degli avvisi nelle scansioni delle vulnerabilità?

Le scansioni CVE (Common Vulnerabilities and Exposures) sono essenziali per proteggere le tue applicazioni software. Tuttavia, con la crescente complessità degli stack software, identificare e gestire tutti i CVE può essere difficile. Uno dei maggiori problemi con le scansioni CVE oggi è la prevalenza di falsi positivi, in cui viene identificata una vulnerabilità in un pacchetto che non è […]