Migliori pratiche per la sicurezza della catena di fornitura del software

La catena di fornitura del software si riferisce a tutto e tutti coloro che sono collegati al codice software in qualche modo durante tutto il ciclo di vita dello sviluppo. Ogni software è composto da diversi componenti. Oltre al codice proprietario scritto da zero, il codice richiede anche infrastrutture software esterne, servizi cloud e sistemi operativi per funzionare correttamente. I registri, i repository, le basi di codice e persino le persone che hanno scritto questo software fanno tutti parte della catena di fornitura del software.

Ogni nodo di questa catena complessa rappresenta un potenziale punto di vulnerabilità che può in qualche modo influire sulle prestazioni e sulla sicurezza del software. La vulnerabilità introdotta in qualsiasi punto lungo questa catena di dipendenze ha gravi conseguenze a valle. Questo perché la complessità della catena di fornitura del software maschera i rischi e rende difficile la previsione e l'identificazione senza un quadro standardizzato per proteggere la catena di fornitura. Questo è il motivo per cui è importante che gli sviluppatori e le organizzazioni di prodotto lo facciano scopri cos'è la sicurezza della catena di fornitura del software.

La sicurezza della catena di fornitura del software si riferisce all'insieme di pratiche standardizzate messe in atto per proteggere il software da potenziali vulnerabilità lungo tutto il ciclo di vita dello sviluppo del software dal punto di sviluppo dell'applicazione e attraverso l'integrazione e la distribuzione continua (pipeline CI/CD).

È importante che i team di sicurezza comprendano e seguano l'elenco delle migliori pratiche di sicurezza della catena di fornitura del software per mantenere sicura la catena di fornitura del software della propria organizzazione. Questo post descrive in dettaglio le migliori pratiche della catena di fornitura che dovresti conoscere.

Migliori pratiche per proteggere la catena di fornitura del software

Questa sezione fa riferimento alle pratiche standard che gli sviluppatori e le organizzazioni di prodotto devono seguire per proteggere la catena di fornitura del software. Puoi utilizzare queste linee guida come quadro di base per descrivere, valutare e misurare le pratiche di sicurezza per la tua organizzazione nelle diverse fasi del ciclo di vita del software. Queste best practice attraversano la fase di acquisizione, sviluppo e distribuzione della catena di fornitura del software per garantire l'integrità dell'ambiente di sviluppo, del codice sorgente e del prodotto finale.

Acquisisci componenti ben protetti

Incorporare componenti di terze parti nel software è una pratica standard per gli sviluppatori, poiché ciò consente loro di sfruttare le capacità API esistenti per fornire le funzionalità desiderate invece di creare da zero. I componenti di terze parti possono presentarsi sotto forma di software proprietario commerciale o di strumenti open source gratuiti. Quando si acquista uno di questi componenti, è importante considerare la sicurezza come uno dei criteri più importanti che il componente software deve soddisfare.

Per determinare la sicurezza dei componenti di terze parti potrebbe essere necessario eseguire analisi di sicurezza avanzate come l'analisi della composizione sicura, l'analisi del database delle vulnerabilità, la valutazione del codice sorgente e l'analisi della valutazione del rischio. Il risultato di questi controlli aiuterà a determinare se questo componente è sicuro e dovrebbe essere consentito per il tuo prodotto

Inoltre, i componenti selezionati devono essere monitorati continuamente utilizzando un servizio automatizzato di tracciamento delle vulnerabilità per identificare le vulnerabilità il prima possibile e rimuoverle tempestivamente.

Crea componenti software sicuri internamente aderendo a pratiche di codifica sicure

Sebbene i componenti software esterni incorporati nel software siano importanti, la sicurezza e l'integrità dei prodotti software dipendono anche dalle pratiche di codifica sicura seguite internamente.

Ogni organizzazione ha bisogno di un quadro completo del ciclo di vita dello sviluppo software che incorpori pratiche di codifica sicure per garantire che gli artefatti creati siano conformi alle linee guida stabilite.

Per cominciare, l'integrità dei tuoi prodotti software e degli artefatti che crei internamente dipende dalla qualità del tuo team. Il tuo team di sviluppo dovrebbe includere esperti di sviluppo, controllo qualità, professionisti della sicurezza informatica e ingegneri di costruzione con una buona conoscenza delle pratiche di sicurezza standard.

Il team di gestione del prodotto dovrebbe includere anche architetti della sicurezza, product manager e leader di prodotto che lavorano per garantire la conformità alle politiche di sviluppo sicure. Alcune delle strategie di base per garantire la creazione interna di artefatti software sicuri includono:

• Generazione di documenti di progettazione e architettura per ciascun artefatto
• Creazione di modelli di minaccia per prodotti software
• Definizione e implementazione dei test di sicurezza
• Impostazione di criteri di rilascio specifici per la valutazione del prodotto
• Stabilire politiche di gestione delle vulnerabilità per ciascun prodotto
• Documentare e pubblicare le procedure di sicurezza per ogni versione del software

 Utilizza catene di strumenti software sicure di terze parti e librerie di compatibilità

Molti ambienti di sviluppo integrato (IDE) utilizzati nel processo di sviluppo del software sono autonomi. Ciò significa che ti consentono di eseguire vari passaggi all'interno del processo di sviluppo come codifica, compilazione, confezionamento e debug del codice, tutto dallo stesso strumento. Alcuni IDE dispongono anche di strumenti per connettere una fonte a un repository esterno. Gli IDE con questa funzione supportano più linguaggi del compilatore. Oltre a queste funzioni principali, gli sviluppatori potrebbero essere in grado di estendere le capacità dell'IDE che utilizzano con i plugin. Questa è una potenziale fonte di vulnerabilità per l’ambiente di sviluppo locale, a causa della complessità di fonti non attendibili come questa.

Per mantenere sicuro il tuo ambiente di sviluppo, tutti gli IDE e i plugin da utilizzare all'interno dell'ambiente devono essere controllati e pre-approvati dopo essere stati scansionati per individuare eventuali vulnerabilità e convalidati.

Oltre ai plug-in che estendono le capacità del tuo ambiente di creazione, un'altra categoria di strumenti di creazione di terze parti di cui potresti dover verificare le vulnerabilità sono le toolchain software e le librerie di compatibilità. Questi strumenti del sistema operativo di terze parti vengono installati nell'ambiente di sviluppo per consentire di utilizzare utilità e comandi specifici univoci per quel sistema operativo. Ad esempio, un ambiente di sviluppo Windows potrebbe richiedere alcuni comandi del sistema operativo esclusivi del sistema operativo Linux durante il processo di creazione per garantire la compatibilità tra entrambi i sistemi durante il processo di produzione.

Allo stesso modo, le librerie di conversione API ti aiutano anche a creare un ambiente di codifica comune per due diversi sistemi operativi. Queste toolchain API sono strumenti commerciali e open source ed è necessario accedervi per individuare eventuali vulnerabilità prima di essere adottate per il tuo ambiente di creazione e utilizzate per il tuo progetto.

Mitigare la modifica o lo sfruttamento del codice sorgente da parte di addetti ai lavori

Secondo la Cybersecurity and Infrastructure Security Agency (CISA), un insider è qualsiasi persona con accesso autorizzato o conoscenza delle risorse di un'organizzazione. Gli individui che hanno o hanno avuto accesso alle strutture, alla rete, alle apparecchiature e ai sistemi dell'utente possono potenzialmente mettere a repentaglio l'integrità del prodotto software, intenzionalmente o inconsapevolmente.

Nell'ambito degli sforzi per proteggere il software, è necessario garantire che il processo di sviluppo disponga di policy per impedire l'esposizione intenzionale o involontaria a codice dannoso nel codice di produzione da parte di addetti interni, ad esempio personale compromesso, ingegneri scarsamente formati o dipendenti inattivi. Alcune delle misure che puoi mettere in atto per mitigare questo problema includono:

• Processo di check-in del codice sorgente equilibrato e autenticato
• Scansione di sicurezza automatizzata per le vulnerabilità
• Formazione sullo sviluppo di software sicuro
• Rafforzare l'ambiente di sviluppo
• Dare priorità alle revisioni del codice

Archivia il codice o gli eseguibili e rivedi tutte le modifiche prima dell'approvazione

Il controllo delle versioni è una delle pratiche standard che possono aiutare a mantenere l'integrità del software. Come parte del processo di integrazione e distribuzione continua (pipeline CI/CD), dovrai mantenere un repository in cui archiviare il codice e gli eseguibili. Ciò fornisce una cronologia operativa del tuo codice in modo da poter monitorare facilmente ciò che è stato inserito nello stack di sviluppo fino a quel momento.

Avrai inoltre bisogno di un sistema di approvazione continua per rivedere tutte le modifiche apportate al tuo software prima che vengano approvate. Ciò è particolarmente utile quando si collabora con altri sviluppatori all'interno dei team. La risoluzione dei problemi è più semplice in questo caso poiché puoi identificare facilmente le modifiche mentre vengono apportate e chi le sta apportando.

Non importa quanto semplice o complesso sia il software che stai creando, un sistema di controllo del codice sorgente o della versione semplifica la visualizzazione e il monitoraggio di tutte le modifiche apportate al codice, il monitoraggio della cronologia delle versioni quando necessario o addirittura il ripristino di una versione precedente del software. codice quando necessario.

Creare e gestire una SBOM per ogni pacchetto software creato

I Distinta dei materiali del software è una documentazione fondamentale che descrive in dettaglio tutti i componenti di terze parti incorporati nel prodotto software. Una SBOM semplifica la convalida di tutti i componenti approvati di un software e l'identificazione semplice di eventuali vulnerabilità o difetti. Per ogni pacchetto software creato, è necessario creare e gestire anche una relativa SBOM.

È possibile preparare una distinta base del software in base alle specifiche definite in formati standard come i tag Software Package Data Exchange (SPDX), CycloneDX e Software Identification (SWID) definiti rispettivamente da Linux, OWASP e NIST.

Per ogni prodotto software creato, i fornitori o i proprietari dei componenti di terze parti utilizzati devono fornire una distinta base dei materiali del software completa. I risultati finali del progetto e le SBOM fornite dal fornitore possono anche essere convalidati utilizzando uno strumento di analisi della composizione (SCA).

Anche se il fornitore non fornisce una SBOM, la SBOM generata con lo strumento di analisi della composizione del software può comunque fornire le informazioni richieste per descrivere i componenti di terze parti del software. Il processo di generazione di SBOM dovrebbe essere automatizzato. Automazione SBOM è fondamentale perché i fornitori e gli sviluppatori di terze parti devono generare una nuova SBOM ogni volta che un software di terze parti viene modificato e farlo manualmente non è pratico. La SBOM aggiornata descriverà eventuali miglioramenti o modifiche nel codice del componente e la loro relazione con il prodotto software.

Rafforzare l'ambiente di costruzione

Uno dei modi per garantire l'integrità del software è rafforzare l'ambiente di sviluppo contro potenziali vulnerabilità. Ciò include sia l'ambiente di sviluppo individuale che l'ambiente di creazione di produzione complessivo.

Indipendentemente dal fatto che il tuo ambiente di creazione sia ospitato nel cloud o in sede, devi configurarlo e adottare misure per proteggere il server e la rete, controllando allo stesso tempo chi ha accesso a cosa. L'esecuzione della due diligence nell'ottimizzazione e nella protezione dell'ambiente di creazione in questo modo garantirà l'integrità del codice sorgente e del prodotto finale.

La protezione della pipeline di creazione implica la protezione di tutti i sistemi utilizzati durante il processo di creazione del prodotto. Ciò include repository di codici, server di firma, workstation di progettazione, server di distribuzione e così via. Alcune delle misure che puoi mettere in atto per proteggere la tua infrastruttura di pipeline di costruzione includono:

Bloccare i sistemi

Per proteggere i tuoi sistemi, dovresti limitare le operazioni di sistema a funzioni specifiche che il sistema è destinato a eseguire. Ad esempio, il tuo sistema di compilazione dovrebbe essere utilizzato solo per operazioni di compilazione e nient'altro.

Limita le attività di rete esterne e fuori LAN

Sia le attività di rete in entrata che quelle in uscita possono potenzialmente esporre il tuo sistema a attacchi. Dovresti bloccare tutte le attività esterne e fuori LAN e limitare le connessioni esterne agli URL necessari.

Monitorare i sistemi per perdite di dati

Per garantire l'integrità del codice sorgente del tuo prodotto, dovresti impostare le tue difese di sicurezza informatica per proteggere il tuo repository, workstation e altre parti del tuo ambiente di creazione dall'esfiltrazione e dall'infiltrazione di dati. Ciò comporta il blocco di tutti i comportamenti dannosi, l’isolamento delle app e la configurazione di sistemi di rilevamento per individuare eventuali intrusioni non appena si verificano.

Configura la pipeline di controllo della versione

La pipeline del codice dovrebbe essere controllata dalla versione. Quando si apportano modifiche al prodotto, gli aggiornamenti devono essere effettuati sul codice di configurazione e non sui sistemi effettivi.

Autenticazione a più fattori

Ogni sistema che fa parte del tuo ambiente di creazione deve essere configurato con l'autenticazione a più fattori, ove possibile. Dovrebbero essere messe in atto anche misure di sicurezza aggiuntive come l’accesso basato sui ruoli, i privilegi minimi e così via. Le linee guida NIST raccomandano inoltre un doppio sistema di autorizzazione per tutti i sistemi critici o sensibili nell'ambiente di costruzione.

Segrega la tua rete di ingegneri

È necessario accedere al sistema di build solo tramite una rete tecnica isolata diversa dal resto della rete della tua organizzazione. Quando possibile, la rete di ingegneria dovrebbe essere offline.

Analizzare ciascuna vulnerabilità per raccogliere informazioni sufficienti per pianificare la sua bonifica

Quando si sviluppa software, è necessario adottare misure per garantire che il prodotto e tutti i suoi componenti siano esenti da vulnerabilità note ad alto rischio. Allo stesso modo, quando un cliente scopre o segnala nuove vulnerabilità, è necessario rispondere immediatamente all'incidente. In alcuni casi, ciò richiederà l'aggiornamento del sistema per mitigare i rischi associati alla vulnerabilità appena scoperta.

I fornitori di software dovrebbero disporre di un processo per accettare aggiornamenti o segnalazioni su potenziali vulnerabilità o difetti nei loro prodotti, da ricercatori o clienti di terze parti. È inoltre necessario disporre di un sistema automatizzato che ti avvisi sugli aggiornamenti di vulnerabilità annunciati da organizzazioni affidabili come la Cybersecurity & Infrastructure Security Agency (CISA).

Ogni organizzazione necessita di una politica interna di gestione delle vulnerabilità conforme alle linee guida standard. Gli avvisi sulle minacce ad alto rischio dovrebbero essere valutati in base alla relazione tra il prodotto e i suoi componenti che potrebbero essere stati interessati dalla vulnerabilità segnalata. Il tuo team di tecnici deve inoltre disporre di un sistema completo per la revisione, la diagnosi e possibilmente la risoluzione dei problemi

Manutenzione dei componenti

Un prodotto software e i suoi componenti non sono mai statici. Dovresti tenere presente che i componenti di terze parti integrati nei tuoi prodotti potrebbero essere modificati o aggiornati periodicamente dal fornitore. Dovresti monitorare queste modifiche soprattutto quando sono correlate a vulnerabilità ed esposizioni comuni (CVE).

Una parte importante della manutenzione dei componenti software consiste nel monitorare i meccanismi di segnalazione CVE standard e altri canali di supporto per determinare se le vulnerabilità appena identificate in un componente di terze parti incorporato nel prodotto influiscono sull'integrità dei propri sistemi e intraprendere azioni appropriate per mitigare i rischi ( se presente).

Quando selezioni componenti di terze parti da includere nel tuo prodotto, dovresti controllare il contratto per assicurarti che il proprietario del componente disponga di politiche su come notificare alle organizzazioni del prodotto gli aggiornamenti ai loro sistemi, la presenza di vulnerabilità e il periodo di tempo per la vulnerabilità risoluzione nonché eventuali azioni che potresti dover eseguire per garantire una sicurezza ottimale.