Quando tre agenzie governative statunitensi si riuniscono per “incoraggiare fortemente” gli sviluppatori ad adottare determinate pratiche, dovresti prestare attenzione. La CISA, la NSA e l'ODNI, riconoscendo la minaccia degli hacker informatici e sulla scia dell'attacco SolarWinds, hanno annunciato che pubblicheranno congiuntamente una raccolta di raccomandazioni per proteggere la catena di fornitura del software per prevenire tali vulnerabilità in futuro . L’annuncio ha chiarito che lo scopo del documento è incoraggiare gli sviluppatori ad adottare le migliori pratiche, affermando che “Questi principi includono la pianificazione dei requisiti di sicurezza, la progettazione dell'architettura software dal punto di vista della sicurezza, l'aggiunta di funzionalità di sicurezza e il mantenimento della sicurezza del software e dell'infrastruttura sottostante."
Questa guida è organizzata come una serie di tre parti e verrà rilasciata in concomitanza con il ciclo di vita della catena di fornitura del software. Parte 1 della serie, che si concentra sulle raccomandazioni per gli sviluppatori di software, è stato rilasciato nell'agosto 2022. Le restanti due parti verranno rilasciate nel prossimo futuro: la parte 2 si concentrerà sui fornitori di software e la parte 3 si concentrerà sui clienti che ricevono il software. L’obiettivo finale è che questa serie contribuisca a promuovere la comunicazione tra queste tre principali parti interessate e tra i professionisti della sicurezza informatica per facilitare una maggiore resilienza e migliorare complessivamente sicurezza della catena di fornitura del software.
Anche se non è sempre chiaro di chi sia la responsabilità di garantire la sicurezza del software, indipendentemente da chi possa avere la responsabilità generale nella vostra specifica organizzazione, questo nuova guida rende molto chiaro che tutti gli sviluppatori dovrebbero acquisire familiarità con queste nuove migliori pratiche e che tutti hanno un ruolo nel garantire la catena di fornitura del software. Oppure, se posso essere più schietto: Sviluppatori, voi giocate un ruolo fondamentale nel proteggere la catena di fornitura del software della vostra organizzazione! E per questo motivo, abbiamo pensato che potrebbe esserti utile leggere, solo per te, un riassunto (relativamente) breve di questa prima parte della guida. Ecco che arriva.
La guida in breve:
Tra gli estesi elenchi di potenziali minacce a cui si fa riferimento in questa guida pratica per sviluppatori, sono state identificate alcune vulnerabilità chiave per le quali dovresti assicurarti di affrontarle e prepararti:
- Funzionalità che non sono state adeguatamente documentate o che implementano funzionalità rischiose
- Cambiamenti nascosti nei presupposti fondamentali della sicurezza tra il momento della valutazione della sicurezza e la consegna del codice
- Cambiamenti aziendali per gli stakeholder della catena di fornitura
- Codifica o pratiche di sicurezza inferiori agli standard
Management, finanza e program manager hanno tutti la responsabilità di garantire la sicurezza della catena di fornitura del software, ma anche l'integrità della stessa sicurezza della catena di fornitura del software spesso dipende dalla vigilanza degli sviluppatori di software e dalla consapevolezza di tutti i soggetti interessati della catena di fornitura. La parte 1 della guida si concentra sul ruolo degli sviluppatori e sulle minacce inerenti a ciascuna fase del processo di sviluppo e offre raccomandazioni per le strategie di mitigazione che dovrebbero diventare pratiche standard.
Fase n. 1: criteri e gestione sicuri del prodotto
Lo sviluppo sicuro inizia con il riconoscimento dell'importanza della sicurezza della catena di fornitura del software da parte di tutti i principali soggetti interessati nei team di prodotto e di sviluppo. Gli scenari di minaccia sono comuni e possono essere chiari a tutti; la sfida è mettere tutti sulla stessa lunghezza d’onda per quanto riguarda le politiche di mitigazione che sono state decise. Queste politiche devono coprire l’intero processo: progettazione e architettura, modellazione delle minacce, codifica, piani di test di sicurezza, criteri di rilascio e come gestire le vulnerabilità in futuro. Parte di ciò include anche la valutazione delle capacità dei team e la garanzia che siano stati adeguatamente formati per i loro compiti, quindi la definizione di pratiche di documentazione, revisioni periodiche della sicurezza e valutazioni delle minacce.
Fase n. 2: sviluppo sicuro del codice
Quando si tratta di sviluppo del codice, le pratiche corrette per la codifica sicura sono già state stabilite nel SSDF. Questo è il motivo per cui, nella misura in cui il linguaggio di programmazione non è stato predeterminato, anche le considerazioni sulla sicurezza dovrebbero far parte di tale decisione. La guida fornisce indicazioni utili per gli sviluppatori, affrontando un'ampia gamma di scenari, come l'inserimento di codice sorgente dannoso da parte di "interni" (ad esempio, sviluppatori), software open source e le migliori pratiche per affrontarlo. Come creare un ambiente sicuro per la codifica (comprese configurazioni di build sicure e strumenti software di terze parti) e successivamente testare la sicurezza di un prodotto integrato. Poiché è probabile che le vulnerabilità emergano anche dopo la consegna, esistono anche raccomandazioni per gestire le vulnerabilità segnalate e garantire che future estensioni software esterne non compromettano l'integrità della sicurezza del prodotto.
Fase n. 3: rafforzare l'ambiente di costruzione
Una volta che il codice è stato sviluppato in modo sicuro, la sicurezza della catena di fornitura del software richiede che l’ambiente di creazione sia rafforzato secondo gli stessi standard del software stesso. Compromettere il sistema di compilazione è un modo interessante per infiltrarsi nel codice, poiché avviene in una fase del processo di sviluppo che è naturalmente meno esaminata dagli sviluppatori.
Fase n. 4: consegna del codice
L'ultimo punto debole affrontato dalla guida riguarda la fase finale della catena di fornitura del software: la consegna del codice. Anche quando il codice è stato adeguatamente protetto fino a questo punto, esistono ancora due vulnerabilità chiave della catena di fornitura che devono essere mitigate. Il primo è la convalida finale del pacchetto, che può essere sfruttata, ad esempio, esponendo inavvertitamente metadati, credenziali dello sviluppatore o inventario open source. L’altro passaggio di cui spesso vengono indagati i punti deboli è il sistema di distribuzione, che potrebbe essere compromesso da un attacco man-in-the-middle che può prendere il controllo di una o più fasi della consegna.
Applicando queste pratiche di mitigazione del rischio a livello di sviluppo del software, i fornitori di software possono evitare i punti deboli che possono portare, ad esempio, all’infiltrazione di aggiornamenti, alla manipolazione della firma del codice e alle “sorprese” nascoste nel codice open source.
Niente pranzo gratis: il costo nascosto del software di terze parti
Una chiave contributo alla velocità dello sviluppatore è diventata la capacità di incorporare in modo efficace software di terze parti. Ciò ha permesso agli sviluppatori di concentrarsi, ad esempio, sull'innovazione o sulla funzionalità, utilizzando componenti già pronti per la scalabilità o le interfacce. Questo maggiore utilizzo di software di terze parti ha creato una sfida importante per la sicurezza della catena di fornitura del software. Oltre a condurre una valutazione di tale codice in conformità con gli stessi standard utilizzati per valutare il proprio, la guida suggerisce di scansionare i file binari per individuare eventuali vulnerabilità e valutare i rischi risultanti. I risultati di questa valutazione dovrebbero tenere conto della decisione di utilizzare o non utilizzare un componente software specifico. La scelta di un componente software deve tener conto anche della sua provenienza; incorporare componenti di terze parti nel tuo codice sorgente è l'inizio di una lunga relazione e dovresti sforzarti di lavorare con partner di cui ti puoi fidare. La proprietà del codice, le pratiche di codifica e le politiche di gestione delle versioni sono solo alcuni dei punti da considerare quando si seleziona una fonte attendibile. Basti pensare a tutti i futuri aggiornamenti, rilasci e lavori di manutenzione per ciascun componente man mano che vengono scoperte nuove minacce. La sfida sarà monitorare tutte le modifiche apportate da terze parti, valutare le vulnerabilità e rispondere di conseguenza, a volte in condizioni di forte pressione temporale.
Aumenta la sicurezza della catena di fornitura del tuo software con una SBOM
Una pratica fondamentale per garantire l'integrità a lungo termine della catena di fornitura del software è mantenere un aggiornamento aggiornato Distinta dei materiali del software (SBOM). La SBOM è un inventario dettagliato dei componenti software che compongono una determinata soluzione.
Ciò ti farà risparmiare tempo e fatica e, soprattutto, ridurrà la tua esposizione alle minacce continue. Ogni componente software incorporato nel prodotto deve essere dotato di una propria SBOM, che deve essere convalidata e unita in un'unica SBOM "master" per il prodotto. Se intendi incorporare componenti che non vengono forniti con una SBOM, dovrai condurre la tua analisi utilizzando gli strumenti di analisi della composizione software (SCA).
Quanto più accurata e descrittiva è la SBOM, tanto più facile sarà gestirla e farvi riferimento. Considerata la velocità vertiginosa con cui i componenti software vengono aggiornati, a SBOM ben strutturato pagherà i dividendi quando sarà il momento di rintracciare e registrare ogni aggiornamento, patch o rilascio. Ancora più importante, una volta scoperta una minaccia alla sicurezza, ogni momento è critico. Ricorda: Il sicurezza della catena di fornitura del software sarà sempre forte quanto il tuo anello più debole. Quando ci sono dozzine di componenti software a rischio, sarai grato di avere una SBOM che contenga tutte le risposte.
Per un flusso di lavoro efficiente, una SBOM utile dovrebbe includere almeno questi tre componenti:
- Campi dati – Questi sono i descrittori dei componenti che hai implementato. Essere in grado di identificare facilmente quali componenti sono stati utilizzati, anche molto tempo dopo il completamento dello sviluppo, aiuta a monitorarne efficacemente le vulnerabilità.
- Supporto per l'automazione – Il monitoraggio automatico degli SBOM richiede che essi siano identificati anche in uno dei formati leggibili dalla macchina accettati.
- Pratiche e promesse – La gestione di una SBOM richiede una comprensione comune delle pratiche di manutenzione, come frequenza delle versioni, dipendenze, incognite note, distribuzione e consegna, controllo degli accessi e come correggere gli errori.
La condivisione della SBOM tra le parti interessate di un prodotto specifico (lo sviluppatore software, il fornitore software e il cliente) aiuta a promuovere la trasparenza e l'allineamento, aumentando la capacità di una catena di fornitura software di difendere il prodotto dalle minacce alla sicurezza. È necessario notare che, date tutte le parti in movimento in una catena di fornitura software, mantenere costantemente tale SBOM, che può essere facilmente consultato, monitorato e mantenuto, è una sfida complessa.
Parole finali: come portare la sicurezza della catena di fornitura del software a un livello superiore?
Poiché la sicurezza della catena di fornitura del software diventa sempre più cruciale, le organizzazioni vengono ripetutamente sfidate a costruire una fiducia trasparente nel software che forniscono o utilizzano. Poiché si prevede che l'adozione della SBOM come best practice crescerà, disporre di uno strumento che consenta di superare questa sfida rappresenta un passo fondamentale verso la sicurezza della catena di fornitura del software. Questo è il motivo per cui abbiamo recentemente lanciato il primo hub di sicurezza basato sull’evidenza per i prodotti software, consentendo ai suoi utenti di creare fiducia nel proprio software tra team e organizzazioni. Questa piattaforma intuitiva aiuterà i team di sviluppo a mitigare i rischi della catena di fornitura del software rendendo la SBOM accessibile, facile da usare e, soprattutto,rendere la sicurezza dei prodotti software trasparente ai clienti, agli acquirenti e ai team di sicurezza.
Se tu, come sviluppatore di software, sei preoccupato per le minacce alla sicurezza della tua catena di fornitura di software, ti invitiamo a farlo provare la piattaforma; è gratuito da usare, senza vincoli. Implementando il nostro flusso di lavoro, sarai in grado di condividere le tue SBOM attraverso la tua catena di fornitura.
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
