Che cos'è la sicurezza della catena di fornitura del software?

La catena di fornitura del software comprende tutto ciò che influenza o gioca un ruolo in un prodotto o un'applicazione durante il suo intero ciclo di vita di sviluppo del software (SDLC).

Negli ultimi anni, gli attacchi alla catena di fornitura del software stanno diventando sempre più diffusi e sofisticati. Nel loro rapporto del 2022, Gartner stati: "Anticipare la continua espansione della superficie di attacco aziendale e aumentare gli investimenti in processi e strumenti per il rilevamento e la risoluzione delle minacce all'identità e l'integrità della catena di fornitura digitale."

È più importante che mai proteggere tutti i componenti, le attività e le pratiche SDLC coinvolte nella creazione e distribuzione del software. I team di sviluppo e i fornitori di software devono garantire di utilizzare solo componenti di codice privi di vulnerabilità note e trovare modi per convalidare l’integrità della loro build, verificando eventuali manomissioni non autorizzate.

Definizione di sicurezza della catena di fornitura del software

La catena di fornitura del software si riferisce a tutto ciò che è coinvolto nello sviluppo di un'applicazione durante l'intero ciclo di vita dello sviluppo del software (SDLC). La creazione e la distribuzione del software richiedono la protezione delle attività, dei processi e dei componenti della catena di fornitura. Ci sono molti fattori da considerare a questo proposito, tra cui codice personalizzato (componenti interni), dipendenze e librerie open source (componenti di terze parti), strumenti e infrastruttura DevOps che compongono il processo CI/CD e infine sviluppatori e DevOps squadre.

È responsabilità delle organizzazioni svolgere queste attività di sicurezza e fornire prova dei propri sforzi in materia di sicurezza ai consumatori.

 

 

Attacchi alle catene di fornitura del software: perché sono così comuni?

Le moderne pipeline software sono ambienti automatizzati che si basano su una varietà di strumenti per l'integrazione e la distribuzione continue. Un progetto software potrebbe finire per includere migliaia di dipendenze open source.

Gli autori malintenzionati possono spacciare per legittime le librerie non autorizzate sfruttando "difetti logici" nei gestori di pacchetti open source. Ad esempio, i pacchetti contenenti malware possono essere attribuiti a manutentori fidati a loro insaputa. Tale fiducia mal riposta può introdurre vulnerabilità problematiche e nascoste nel codice. Queste vulnerabilità possono fornire agli aggressori l’accesso a dati sensibili o consentire loro di installare malware e sistemi di controllo lungo tutta la catena di fornitura.

Il moderno ambiente di sviluppo presenta le proprie vulnerabilità e una serie di attacchi alla catena di fornitura del software hanno preso di mira la pipeline CI/CD per inserire codice dannoso a un certo punto del processo di sviluppo. Anche in questo caso, un presupposto di zero trust è l'approccio adeguato per ottenere fiducia nel prodotto software finale: controllare, verificare e convalidare ogni fase della catena di sviluppo interno.
Le pipeline CI/CD odierne non dispongono di visibilità e controlli per proteggere adeguatamente il processo di sviluppo del software. Inoltre, faticano a rilevare la manomissione del codice, rendendo questo vettore di attacco ancora più attraente.

L'SSDF (NIST 800-218) è stato finalizzato ed è in vigore

Il quadro SSDF (NIST 800-218). richiede ai fornitori di implementare pratiche di sicurezza che coprano il ciclo di vita dello sviluppo del software (SDLC). Promuove la trasparenza e misure anti-manomissione nel tentativo di ridurre le vulnerabilità della sicurezza e le interferenze dannose.

Nello specifico, contiene linee guida per un approccio basato sull'evidenza per proteggere il software stesso da eventuali manomissioni.

L’SSDF è composto da quattro parti principali:

01 /
Preparare l'Organizzazione (PO):

Garantire che le persone siano preparate e che i processi e la tecnologia siano in atto per eseguire uno sviluppo software sicuro a livello di organizzazione e, in alcuni casi, per singoli gruppi o progetti di sviluppo.

02 /
Proteggi il software (PS):

Proteggere tutti i componenti software da qualsiasi accesso non autorizzato o manomissione.

03 /
Produrre software ben protetto (PW):

Produrre software ben protetto con vulnerabilità di sicurezza minime nelle sue versioni.

04 /
Rispondere alle vulnerabilità (RV):

Identificare le vulnerabilità residue nelle versioni software, rispondere in modo appropriato per affrontare tali vulnerabilità e prevenire il verificarsi di vulnerabilità simili in futuro.

Non dovresti fare riferimento all’SSDF come a una lista di controllo ma piuttosto come a una guida per pianificare e implementare un approccio basato sul rischio e sull’evidenza per lo sviluppo di software sicuro.
Le aziende devono adottare misure per migliorare la propria posizione in materia di sicurezza al fine di facilitare la conformità ai cambiamenti normativi emergenti.

SLSA è un framework che dovresti rispettare

Un framework ideato da Google, chiamato SLSA (Supply-chain Levels for Software Artifacts), fornisce linee guida su come raggiungere quattro livelli di protezione della catena di fornitura del software. Il framework si concentra sull'integrità della creazione degli artefatti con l'intento di prevenire la manomissione e proteggere gli artefatti.

SLSA funziona in questo modo: implementi elenchi di controllo dei controlli di sicurezza che dovresti implementare nella tua pipeline e questi controlli si trovano in sottodomini come sistemi di controllo del codice sorgente, sistemi di build e dipendenze che inserisci nei tuoi progetti software.

La SLSA prevede quattro livelli di conformità con l'obiettivo di arrivare al livello 4, che avrebbe il valore di sicurezza più elevato, ma avrebbe un elenco di requisiti più lungo.

Il quadro SLSA si basa sul concetto di provenienza. Un documento che rappresenta una “catena di prove” che denota l'origine dei manufatti e il processo di costruzione. Man mano che si salgono i livelli SLSA, è necessario proteggere meglio le prove stesse.

Dovresti considerare SLSA come uno standard di settore, un livello riconoscibile e concordato di protezione e conformità a cui devi aderire.

Come proteggere la catena di fornitura del software?

I diversi framework che abbiamo menzionato definiscono i principi per proteggere la catena di fornitura del software e richiedono la vostra attenzione.

Ci teniamo però a sottolinearlo tre classi principali di controlli di sicurezza:

1. Proteggi la configurazione del tuo ciclo di vita di sviluppo software

Credenziali compromesse, controllo insufficiente delle autorizzazioni e sistemi di build vulnerabili creano superfici di attacco che colpiscono il produttore del software. Gli aggressori che sfruttano queste vulnerabilità possono rubare segreti non protetti o manomettere gli artefatti software. Una gamma di soluzioni commerciali e open source in questa classe può fornire controlli per mappare le lacune nella situazione di sicurezza e porvi rimedio.

2. Evitare di fare affidamento su dipendenze vulnerabili o dannose

Invariabilmente, nuove vulnerabilità continueranno a essere scoperte nel software open source e commerciale. I produttori di software devono mitigare questo rischio aggiornando i componenti open source vulnerabili, analizzando le vulnerabilità autoinflitte nel loro codice proprietario e informando i consumatori di software sulla distinta base del software (SBOM) e sulle implicazioni ad essa associate. Questi consumatori possono, a loro volta, agire di conseguenza.

Account di progetti open source violati e pacchetti dannosi mascherati da legittimi comportano rischi aggiuntivi, che riguardano principalmente il furto di segreti dalle pipeline. La comunità open source e alcuni fornitori commerciali stanno lavorando per risolvere questo problema migliorando la reputazione e il rilevamento di comportamenti dannosi.

3. Convalidare l'integrità e la creazione sicura degli artefatti software

La sicurezza informatica richiede una difesa in profondità. Gli attacchi possono passare inosservati quando si utilizza il tradizionale approccio alla protezione basato sulla riduzione, il rilevamento e la reputazione della superficie di attacco. Inoltre, al giorno d'oggi, i consumatori di software a valle hanno poca influenza su questi controlli. Al massimo, possono fare affidamento su controlli di sicurezza puntuali, come la scansione del codice che fornisce un'istantanea della vulnerabilità, di fornitori che non creano una reale fiducia che l'artefatto software sia ben protetto e protetto durante il ciclo di vita dello sviluppo.

È ora disponibile una nuova classe emergente di controlli che attesta continuamente l'integrità di ogni build di artefatto software e il processo di sviluppo sicuro. Queste attestazioni non sono affidabili e possono essere condivise tra produttori e consumatori a valle in cerca di convalida. Il non ripudio si ottiene mediante metodi crittografici e, pertanto, aumenta significativamente il prezzo per qualsiasi utente malintenzionato che si infiltri nella catena di approvvigionamento.

Questo approccio è considerato essenziale dagli esperti nel campo della sicurezza della catena di fornitura del software. Tuttavia, sebbene esistano alcuni elementi costitutivi open source per supportare questa classe di controlli, solo pochi fornitori possono fornire una soluzione integrata.

Una soluzione completa per la catena di fornitura del software deve includere:

La raccolta di prove e la loro firma come attestazioni dai processi di sviluppo e creazione del software. In genere, questa prova è costituita da hash di file con metadati che vengono confrontati tra passaggi rilevanti del processo, eventi relativi a passaggi relativi alla sicurezza come identità di committenti del codice, revisioni del codice, test di sicurezza automatici e così via. È inoltre necessario fornire un'attestazione relativa al livello di sicurezza del processo di creazione del produttore del software al momento della creazione dell'artefatto software.

Un archivio di attestazioni sicuro che consente visibilità e supporta analisi come la convalida dell'integrità del codice.

Un motore di policy che misura queste attestazioni rispetto a una policy definita dall'organizzazione o basata su standard per la convalida e la dimostrazione della conformità.

Un hub di condivisione di informazioni relative alla fiducia tra produttori o consumatori di software; questo potrebbe essere inter o intra-impresa).

Scopri di più

La convalida dell'integrità del software è impegnativa

Teoricamente controllare l'integrità del codice dovrebbe essere facile. Basta confrontare i file, giusto? In realtà c’è molto da considerare. Per cominciare, ogni lingua compila i file in modo diverso. Inoltre, i file vengono utilizzati in modo molto diverso a seconda del loro scopo. Alcuni sono destinati a cambiare, mentre altri vengono eliminati e altri vengono creati durante il processo di compilazione.

A ciò si aggiunge il fatto che le aziende non vogliono cedere reciprocamente il proprio codice proprietario.

Garanzia del codice durante l'intero SDLC

Scribe si propone di proteggere continuamente l'intero SDLC. Con le prove raccolte da varie parti del processo di sviluppo e creazione, Scribe utilizza la firma digitale per creare attestazioni non falsificabili.

Una volta firmata, ogni prova può essere successivamente verificata per garantire che tutti i processi si siano svolti come previsto e che non siano state apportate modifiche impreviste.

Seguendo le migliori pratiche stabilite nell'SSDF, Scribe ti consente di utilizzare politiche di buon senso per aumentare la tua fiducia durante tutto il processo di sviluppo. Politiche come la richiesta di commit firmati, 2FA per gli sviluppatori, revisione del codice da parte di 2 persone, ecc., aiutano a generare fiducia che ogni pezzo di software sia stato prodotto seguendo il corretto atteggiamento di sicurezza.

La raccolta di tutte queste prove in un'unica posizione, insieme a un rapporto sull'integrità del codice e a un riepilogo di tutte le politiche e le attestazioni, consente maggiore visibilità e fiducia nel processo di sviluppo e negli artefatti software prodotti alla fine ed è in linea con le linee guida SSDF che stanno in piedi alla base della nuova regolamentazione cyber.

Consentire ad abbonati selezionati di visualizzare la conformità del prodotto ai requisiti delle policy e ai risultati di integrità offre agli utenti maggiore visibilità e fiducia nelle pipeline di sviluppo e nel prodotto software finale.

Il risultato finale non è solo il rilevamento di manomissioni del codice o della pipeline, ma anche la capacità di attestare i test e le procedure di sicurezza avvenute durante la progettazione e la realizzazione del software, nonché l'integrità del codice sorgente e dei pacchetti open source. utilizzato per costruirlo.

Scopri di più

Spiegazione della sicurezza della catena di fornitura del software

Cosa si nasconde nel tuo codice?

Come migliorare la fiducia nella catena di fornitura del software?

Quali sono le implicazioni della versione finale di SSDF (NIST 800-218)?

Cosa significano la garanzia continua e la sicurezza della catena di fornitura del software?

Perché la garanzia continua è una pratica integrale per la sicurezza della catena di fornitura del software?

Come implementare la valutazione automatizzata della conformità SLSA?

In che modo la SBOM può migliorare la sicurezza della catena di fornitura del software?

Come proteggere il tuo software con le SBOM?

Automatizzazione della valutazione della conformità SLSA

La sicurezza delle condotte dinamiche deve essere costantemente misurata. SLSA (Supply-chain Levels for Software Artifacts) definisce quattro livelli di protezione della catena di fornitura del software insieme a linee guida su come raggiungerli.

Una valutazione della conformità SLSA può essere automatizzata per soddisfare i requisiti. Ma come dovrebbe procedere un’organizzazione per acquisirne uno? Ci sono best practice specifiche che dovresti seguire?

Guarda questo video in cui condividiamo le migliori pratiche per l'implementazione dell'automazione, utilizzando strumenti open source come Sigstore e OPA in scenari reali. Le migliori pratiche concettuali e tecniche fanno luce sui dettagli del mondo reale e sulle sfide legate alla valutazione e all'automazione della conformità SLSA.

Prima di usare Scribe Dopo aver usato Scribe
Trust Hub: condivisione delle informazioni

  • Una SBOM generata viene salvata localmente per singola pipeline, senza la possibilità di gestirla o condividerla con le parti interessate all'interno dell'organizzazione o esternamente.

  • Condivisione e gestione delle SBOM, sia internamente all'organizzazione con altri stakeholder che esternamente con clienti o utenti
  • SBOM intelligente con informazioni fruibili
  • Gli approfondimenti SBOM possono essere utilizzati come un "cancello" go/no-go sulla pipeline o sul prodotto, utilizzato per determinare se l'immagine risultante corrisponde a quanto previsto
  • Ora è possibile la sincronizzazione tra diversi team e organizzazioni
SDLC sicuro: policy e conformità

  • Non esiste un modo automatico o resiliente per garantire che le politiche SDLC sicure siano state seguite come richiesto.

  • Un modo affidabile basato sull'evidenza che garantisce che le policy SDLC sicure siano state applicate secondo le più recenti normative e quadri di sicurezza della catena di fornitura del software (SLSA 3, SSDF)
Rilevamento di integrità e manomissione

  • Solo ciò che puoi ricavare da log e API
  • Non firmato fino alla fine del processo, subito prima della consegna (si riferisce solo al MITM "final lag")

  • La continua garanzia del codice utilizzando l'hashing e la firma continui del codice in ogni fase del processo di sviluppo consente di verificare che l'artefatto finale sia quello che doveva essere e che nessun codice dannoso sia stato inserito da un utente malintenzionato durante i processi di sviluppo e distribuzione.
Visibilità

  • Tutto ciò che puoi ricavare da log e API
  • Salvato localmente e non firmato, con la possibilità che attori malintenzionati lo abbiano manomesso

  • Attestazioni firmate salvate in un archivio di prove separato, sicuro e a prova di manomissione
Atteggiamento di sicurezza

  • Controllo delle configurazioni errate degli strumenti CI/CD
  • Alla ricerca di segreti trapelati
  • Verifica delle vulnerabilità note (CVE)

  • Verifica delle lacune SDLC nella catena di strumenti CI/CD.
  • Verifica delle vulnerabilità note (CVE) e della reputazione dei repository OSS
  • Registrazione di attestazioni a prova di manomissione che le misure di sicurezza richieste sono state adottate in tempo in ogni fase del processo secondo la politica SDLC delle organizzazioni.

Scribe Security: un nuovo standard di sicurezza della catena di fornitura del software

La Continuous Code Assurance comprende processi e strumenti che:

Tieni traccia di ogni dettaglio ed evento nel processo di sviluppo del software, nonché dell'integrità dei componenti e degli artefatti del software

Verificare che non si sia verificata alcuna manomissione in nessuna parte del processo di sviluppo del software

Verificare l'integrità degli strumenti CI/CD utilizzati per creare il codice

Confermare l'integrità del processo di sviluppo, assicurando che i passaggi relativi alla sicurezza siano stati condotti secondo la politica dell'organizzazione e non siano stati aggirati

Raccogliendo e firmando prove di qualsiasi cosa accada al codice, in ogni fase del ciclo di vita dello sviluppo rendi più difficile per gli aggressori manomettere file, strumenti o il comportamento previsto della pipeline CI/CD.

Per saperne di più

Come possiamo aiutarti? AIUTO?

La nostra piattaforma unica garantisce che gli artefatti del codice siano protetti da Git alla produzione durante l'intero ciclo di vita dello sviluppo del software, utilizzando i principali concetti e framework di sicurezza.

I nostri clienti, responsabili della protezione delle build software e del software in uso, si affidano a Scribe per garantire che il loro software sia sicuro e affidabile.

Contattaci

Stay in the Know

Garanzia continua e sicurezza della catena di fornitura del software | Scriba Sicurezza Rischio informatico
Garanzia continua: una pratica integrale per la sicurezza della catena di fornitura del software
Per saperne di più
VERSIONE FINALE SSDF Rischio informatico
Versione finale SSDF (NIST 800-218): differenze rispetto alla bozza e relative implicazioni per te
Per saperne di più
Immagine dell'articolo IconBurst Rischio informatico
IconBust, un nuovo attacco NPM
Per saperne di più

Negli ultimi anni gli attacchi alla catena di fornitura del software sono diventati più diffusi e sofisticati. Secondo a Relazione Gartner, si prevede che il numero di attacchi alla catena di fornitura del software triplicherà entro il 2025, colpendo quasi la metà di tutte le organizzazioni a livello mondiale. A causa di questa crescente minaccia, la protezione di tutti i componenti, le attività e le pratiche SDLC è più importante che mai.

Mentre è difficile da prevenire attacchi alla catena di fornitura del software, di seguito sono elencate alcune delle cose che puoi fare per mitigarne l'impatto o ridurne i rischi: controllare la tua infrastruttura, tenere un inventario aggiornato di tutte le risorse software, valutare i fornitori e applicare un approccio zero-trust, utilizzare strumenti di sicurezza, proteggere il tuo endpoint, ecc.

Anche se non ci sono garanzie nella vita, tanto meno nella sicurezza, ce ne sono migliori pratiche per la sicurezza della catena di fornitura del software in atto, che gli sviluppatori e le organizzazioni di prodotto devono seguire per proteggere la catena di fornitura del software. Nelle diverse fasi del ciclo di vita del software, puoi utilizzare queste linee guida per descrivere, valutare e misurare le pratiche di sicurezza all'interno della tua organizzazione. Le migliori pratiche entrano in gioco in ogni fase della catena di fornitura del software, inclusi acquisizione, sviluppo e distribuzione.

Un aumento del numero di rischi della catena di fornitura del software e una serie di violazioni di alto profilo che ne derivano mostrano quanto sia grave il problema di vulnerabilità. Esistono diverse minacce alla catena di fornitura del software che possono essere poste dal software di terze parti. Gli aggressori possono sfruttare in diversi modi le vulnerabilità dei sistemi che dipendono da software di terzi. Tra questi metodi di attacco figurano l'introduzione di codice dannoso nel software, causando confusione tra le dipendenze e typosquatting.

Gli attacchi alla supply chain solitamente si nascondono dietro processi legittimi per ottenere accesso illimitato all'ecosistema software di un'organizzazione. Nella maggior parte dei casi, gli aggressori iniziano violando le difese di sicurezza di un fornitore o di un fornitore di software. Una volta che il malware della catena di approvvigionamento è stato iniettato, deve collegarsi a un processo legittimo firmato digitalmente. Gli aggiornamenti software vengono spesso utilizzati dagli aggressori per diffondere malware lungo la catena di fornitura del software. Alcuni dei comuni tipi di attacchi alla catena di fornitura del software includono: strumenti di creazione di software compromessi, certificati di firma del codice rubati o app dannose firmate che utilizzano un'identità rubata e codice compromesso in componenti hardware o firmware.

Una SBOM (Distinta dei materiali del software), è un insieme di informazioni sui numerosi componenti che compongono un prodotto o un'applicazione software. Di solito contiene informazioni sulla licenza, numeri di versione, dettagli sui componenti, fornitori, ecc. Un elenco così dettagliato e formale riduce i rischi sia per il produttore che per l'utente consentendo ad altri di capire cosa c'è nel loro software e agire di conseguenza.

Le SBOM consentono la visibilità dei componenti del prodotto, consentono una scansione più semplice delle vulnerabilità, sfruttano la governance delle licenze e possono essere utilizzate per analizzare le minacce all'integrità.

La Continuous Assurance mira a dissipare i punti ciechi della catena di fornitura del software. Implica la raccolta di prove firmate su ogni evento nel ciclo di vita dello sviluppo che potrebbe influire sulla sicurezza del prodotto software finale, comprese la creazione e l'implementazione del prodotto. Oggi le aziende utilizzano una varietà di strumenti di sicurezza per rendere i propri prodotti software più sicuri. Tuttavia, raramente stabiliscono una politica per l’uso coerente di questi strumenti.

Garanzia continua garantisce che i prodotti software non siano stati manomessi durante lo sviluppo e che siano stati eseguiti test relativi alla sicurezza.

Piccole modifiche al codice potrebbero non essere rilevate per molto tempo. I team di sviluppo si fidano del proprietario del codice se il prodotto modificato è firmato correttamente. Di conseguenza, i pacchetti contenenti malware possono essere creati e assegnati a manutentori famosi e affidabili a loro insaputa. Un caso di fiducia malriposta potrebbe significare una vulnerabilità problematica o totale codice dannoso nascosto nel tuo codice.

È anche comune che gli sviluppatori copino e incollino codice da librerie esistenti o StackOverflow da utilizzare nel proprio codice o da caricare in nuove librerie. Ciò aumenta le possibilità di copiare anche codice non sicuro e vulnerabile che ora è sostanzialmente non tracciabile. 

La versione finale di NIST SSDF 1.1 (Secure Software Development Framework) è stata rilasciata il 22 marzo. Nel settembre 2021 è stata pubblicata una bozza del quadro. Molte delle differenze sono incentrate sui vari esempi forniti piuttosto che su pratiche e compiti di alto livello.

Nel decidere quali pratiche implementare, il NIST raccomanda di bilanciare il rischio con i costi, la fattibilità e l’applicabilità. Per garantire la sicurezza del software, l’automazione del maggior numero possibile di controlli e processi è una caratteristica fondamentale da considerare.

Costruire la fiducia nel tuo software è un compito importante, soprattutto alla luce dei nuovi standard e delle migliori pratiche, come SSDF e SLSA. Presto i venditori che non potranno dimostrare questa fiducia non potranno vendere al governo federale degli Stati Uniti.

Per creare fiducia, dovresti conservare e condividere con le parti interessate la SBOM dei tuoi prodotti insieme alle prove sul loro sviluppo e costruzione sicuri.

Piattaforma Scriba, una soluzione di sicurezza della catena di fornitura software veramente end-to-end, ti offre questa funzionalità. Applica la garanzia continua del codice in tutto l'SDLC con un approccio zero-trust e genera automaticamente SBOMS condivisibili in modo da poter ottenere informazioni dettagliate sulle vulnerabilità e sulla manomissione del codice.

Le pipeline dinamiche devono essere continuamente monitorate per motivi di sicurezza. In Quadro di sicurezza informatica SLSA (Supply Chain Levels for Software Artifacts), vengono definiti quattro livelli di protezione per le catene di fornitura del software, insieme a linee guida su come raggiungere ciascun livello.

È necessario seguire le migliori pratiche per implementare l'automazione, utilizzando strumenti open source come Sigstore e OPA, solo per citarne alcuni.