Procedure consigliate per una catena di approvvigionamento del software sicura

Open Source è ovunque. Si trova in molte codebase proprietarie e progetti della community. Per le organizzazioni e le persone, la domanda odierna non è se si sta usando codice open source, ma quale codice open source si sta usando e quanto.

Se non si è a conoscenza di ciò che si trova nella supply chain del software, una vulnerabilità upstream in una delle dipendenze può essere irreversibile, rendendo l'utente e i clienti vulnerabili a un potenziale compromesso. In questo documento verranno approfonditi i termini "catena di approvvigionamento software", perché è importante e come è possibile proteggere la supply chain del progetto con le procedure consigliate.

Dipendenze

Il termine catena di approvvigionamento software viene usato per fare riferimento a tutto ciò che entra nel software e da dove proviene. Si tratta delle dipendenze e delle proprietà delle dipendenze da cui dipende la supply chain del software. Una dipendenza è ciò che il software deve essere eseguito. Può essere codice, file binari o altri componenti e da dove provengono, ad esempio un repository o una gestione pacchetti.

Include chi ha scritto il codice, quando è stato contribuito, come è stato esaminato per problemi di sicurezza, vulnerabilità note, versioni supportate, informazioni sulle licenze e solo qualsiasi elemento che lo tocca in qualsiasi punto del processo.

La supply chain comprende anche altre parti dello stack oltre una singola applicazione, ad esempio gli script di compilazione e creazione di pacchetti o il software che esegue l'infrastruttura su cui si basa l'applicazione.

Vulnerabilità

Oggi, le dipendenze software sono diffuse. È piuttosto comune per i progetti usare centinaia di dipendenze open source per le funzionalità che non è necessario scrivere manualmente. Ciò può significare che la maggior parte dell'applicazione è costituita da codice che non è stato creato.

Le possibili vulnerabilità nelle dipendenze open source o di terze parti sono presumibilmente dipendenze che non è possibile controllare altrettanto strettamente come il codice scritto, che può creare potenziali rischi per la sicurezza nella catena di fornitura.

Se una di queste dipendenze presenta una vulnerabilità, è probabile che si verifichi anche una vulnerabilità. Questo può essere spaventoso perché una delle dipendenze può cambiare senza neanche sapere. Anche se una vulnerabilità esiste attualmente in una dipendenza, ma non è sfruttabile, può essere sfruttata in futuro.

Essere in grado di sfruttare il lavoro di migliaia di sviluppatori e autori di librerie open source significa che migliaia di sconosciuti possono contribuire in modo efficace direttamente al codice di produzione. Il prodotto, attraverso la supply chain del software, è interessato da vulnerabilità senza patch, errori innocenti o persino attacchi dannosi contro le dipendenze.

Compromissioni della catena di approvvigionamento

La definizione tradizionale di una catena di approvvigionamento deriva dalla produzione; è la catena di processi necessari per fare e fornire qualcosa. Include pianificazione, fornitura di materiali, produzione e vendita al dettaglio. Una catena di approvvigionamento software è simile, tranne che invece di materiali, è codice. Invece di produrre, si tratta di sviluppo. Invece di scavare il minerale dal suolo, il codice viene originato da fornitori, commerciali o open source e, in generale, il codice open source proviene da repository. L'aggiunta di codice da un repository significa che il prodotto assume una dipendenza da tale codice.

Un esempio di attacco della supply chain software si verifica quando il codice dannoso viene aggiunto intenzionalmente a una dipendenza, usando la catena di fornitura di tale dipendenza per distribuire il codice alle vittime. Gli attacchi alla catena di approvvigionamento sono reali. Esistono molti metodi per attaccare una supply chain, dall'inserimento diretto di codice dannoso come nuovo collaboratore, all'acquisizione dell'account di un collaboratore senza che altri utenti notino o persino compromettendo una chiave di firma per distribuire software che non fa ufficialmente parte della dipendenza.

Un attacco a catena di approvvigionamento software è in e di se stesso raramente l'obiettivo finale, piuttosto è l'inizio di un'opportunità per un utente malintenzionato di inserire malware o fornire un backdoor per l'accesso futuro.

Software senza patch

L'uso di open source oggi è significativo e non si prevede di rallentare in qualsiasi momento presto. Dato che non smettiamo di usare software open source, la minaccia per la sicurezza della catena di approvvigionamento è un software senza patch. In che modo è possibile affrontare il rischio che una dipendenza del progetto abbia una vulnerabilità?

• Sapere cosa si trova nell'ambiente. Ciò richiede l'individuazione delle dipendenze e le eventuali dipendenze transitive per comprendere i rischi di tali dipendenze, ad esempio vulnerabilità o restrizioni di licenza.
• Gestire le dipendenze. Quando viene individuata una nuova vulnerabilità di sicurezza, è necessario determinare se si è interessati e, in tal caso, eseguire l'aggiornamento alla versione più recente e alla patch di sicurezza disponibile. Ciò è particolarmente importante per esaminare le modifiche che introducono nuove dipendenze o controllano regolarmente le dipendenze meno recenti.
• Monitorare la catena di approvvigionamento. Questo avviene controllando i controlli disponibili per gestire le dipendenze. Ciò consentirà di applicare condizioni più restrittive da soddisfare per le dipendenze.

Verranno illustrati vari strumenti e tecniche forniti da NuGet e GitHub, che è possibile usare oggi per affrontare i potenziali rischi all'interno del progetto.

Conoscenza di ciò che si trova nell'ambiente

Grafico delle dipendenze NuGet

📦 Consumer di pacchetti

È possibile visualizzare le dipendenze NuGet nel progetto esaminando direttamente il rispettivo file di progetto.

Questo si trova in genere in una delle due posizioni seguenti:

• packages.config : si trova nella radice del progetto.
• <PackageReference> : si trova nel file di progetto.

A seconda del metodo usato per gestire le dipendenze NuGet, è anche possibile usare Visual Studio per visualizzare le dipendenze direttamente in Esplora soluzioni o nuGet Gestione pacchetti.

Per gli ambienti dell'interfaccia della riga di comando, è possibile usare il dotnet list package comando per elencare le dipendenze del progetto o della soluzione.

Per altre informazioni sulla gestione delle dipendenze NuGet, vedere la documentazione seguente.

Grafico delle dipendenze di GitHub

📦 Consumer di pacchetti | 📦🖊 Autore del pacchetto

È possibile usare il grafico delle dipendenze di GitHub per visualizzare i pacchetti da cui dipende il progetto e dai repository che dipendono da esso. Ciò consente di visualizzare eventuali vulnerabilità rilevate nelle relative dipendenze.

Per altre informazioni sulle dipendenze del repository GitHub, vedere la documentazione seguente.

Versioni delle dipendenze

📦 Consumer di pacchetti | 📦🖊 Autore del pacchetto

Per garantire una catena di approvvigionamento sicura delle dipendenze, è necessario assicurarsi che tutte le dipendenze e gli strumenti vengano aggiornati regolarmente alla versione stabile più recente, perché spesso includono le funzionalità più recenti e le patch di sicurezza per le vulnerabilità note. Le dipendenze possono includere codice a seconda dei file binari usati, degli strumenti usati e di altri componenti. Questo può includere:

• Visual Studio
• .NET SDK & Runtime
• NuGet
• Pacchetti NuGet

Gestire le dipendenze

Dipendenze deprecate e vulnerabili di NuGet

📦 Consumer di pacchetti | 📦🖊 Autore del pacchetto

È possibile usare l'interfaccia della riga di comando dotnet per elencare tutte le dipendenze note deprecate o vulnerabili presenti all'interno del progetto o della soluzione. È possibile usare il comando dotnet list package --deprecated o dotnet list package --vulnerable per fornire un elenco di eventuali deprecazioni o vulnerabilità note.

Dipendenze vulnerabili di GitHub

📦 Consumer di pacchetti | 📦🖊 Autore del pacchetto

Se il progetto è ospitato in GitHub, è possibile sfruttare GitHub Security per trovare vulnerabilità ed errori di sicurezza nel progetto e Dependabot li correggerà aprendo una richiesta pull sulla codebase.

Intercettare le dipendenze vulnerabili prima di essere introdotte è un obiettivo dello spostamento "Maiusc a sinistra". La possibilità di avere informazioni sulle dipendenze, ad esempio la licenza, le dipendenze transitive e l'età delle dipendenze consente di farlo.

Per altre informazioni sugli avvisi di Dependabot e sugli aggiornamenti della sicurezza, vedere la documentazione seguente.

Feed NuGet

📦 Consumer di pacchetti

Quando si usano più feed di origine NuGet pubblici e privati, è possibile scaricare un pacchetto da uno dei feed. Per garantire che la compilazione sia prevedibile e sicura da attacchi noti, ad esempio Confusione delle dipendenze, sapere quali feed specifici provengono dai pacchetti è una procedura consigliata. È possibile usare un singolo feed o feed privato con funzionalità di upstreaming per la protezione.

Per altre informazioni su come proteggere i feed dei pacchetti, vedere 3 Modi per attenuare i rischi quando si usano feed di pacchetti privati.

Quando si usa un feed privato, vedere le procedure consigliate per la sicurezza per la gestione delle credenziali.

Criteri di attendibilità client

📦 Consumer di pacchetti

Esistono criteri in cui è possibile acconsentire esplicitamente in cui è necessario che i pacchetti usati siano firmati. In questo modo è possibile considerare attendibile un autore del pacchetto, purché sia firmato dall'autore o considerare attendibile un pacchetto se è di proprietà di un utente o di un account specifico firmato da NuGet.org.

Per configurare i criteri di attendibilità client, vedere la documentazione seguente.

File di blocco

📦 Consumer di pacchetti

I file di blocco archiviano l'hash del contenuto del pacchetto. Se l'hash del contenuto di un pacchetto che si vuole installare corrisponde al file di blocco, garantisce la ripetibilità dei pacchetti.

Per abilitare i file di blocco, vedere la documentazione seguente.

Mapping origine pacchetto

📦 Consumer di pacchetti

Mapping origine pacchetti consente di dichiarare centralmente da quale origine ogni pacchetto nella soluzione deve eseguire il ripristino nel file nuget.config.

Per abilitare il mapping dell'origine dei pacchetti, vedere la documentazione seguente.

Monitorare la catena di approvvigionamento

analisi dei segreti di GitHub

📦🖊 Autore del pacchetto

GitHub analizza i repository per le chiavi API NuGet per evitare usi fraudolenti di segreti di cui è stato accidentalmente eseguito il commit.

Per altre informazioni sull'analisi dei segreti, vedere Informazioni sull'analisi dei segreti.

Firma del pacchetto autore

📦🖊 Autore del pacchetto

La firma dell'autore consente a un autore del pacchetto di contrassegnare la propria identità in un pacchetto e di verificare che provenisse dall'utente. Questo ti protegge dalle manomissioni dei contenuti e funge da singola fonte di verità sull'origine del pacchetto e sull'autenticità del pacchetto. In combinazione con i criteri di attendibilità client, è possibile verificare che un pacchetto provenisse da un autore specifico.

Per creare la firma di un pacchetto, vedere Firmare un pacchetto.

Compilazioni riproducibili

📦🖊 Autore del pacchetto

Le compilazioni riproducibili creano file binari che sono byte per byte identici ogni volta che lo si compila e contengono collegamenti al codice sorgente e metadati del compilatore che consentono a un consumer di pacchetti di ricreare direttamente il file binario e verificare che l'ambiente di compilazione non sia stato compromesso.

Per altre informazioni sulle compilazioni riproducibili, vedere Produzione di pacchetti con collegamento di origine e specifica di convalida della compilazione riproducibile.

Two-Factor Authentication (2FA)

📦🖊 Autore del pacchetto

Per ogni account in nuget.org è abilitata la funzionalità 2FA. In questo modo viene aggiunto un ulteriore livello di sicurezza quando si accede all'account GitHub o all'account NuGet.org.

Prenotazione del prefisso dell'ID del pacchetto

📦🖊 Autore del pacchetto

Per proteggere l'identità dei pacchetti, è possibile riservare un prefisso ID pacchetto con il rispettivo spazio dei nomi per associare un proprietario corrispondente se il prefisso ID pacchetto rientra correttamente nei criteri specificati.

Per informazioni sulla prenotazione dei prefissi ID, vedere Prenotazione del prefisso ID pacchetto.

Deprecazione e annullamento dell'elenco di un pacchetto vulnerabile

📦🖊 Autore del pacchetto

Per proteggere l'ecosistema di pacchetti .NET quando si è a conoscenza di una vulnerabilità in un pacchetto creato, è consigliabile deprecare e rimuovere l'elenco del pacchetto in modo che sia nascosto agli utenti che cercano pacchetti. Se si utilizza un pacchetto deprecato e non elencato, è consigliabile evitare di usare il pacchetto.

Per informazioni su come deprecare e rimuovere l'elenco di un pacchetto, vedere la documentazione seguente sulla deprecazione e l'annullamento dell'elenco dei pacchetti.

Riepilogo

La supply chain del software è qualsiasi elemento che entra o influisce sul codice. Anche se i compromessi della supply chain sono reali e in crescita in popolarità, sono ancora rari; quindi la cosa più importante che è possibile fare è proteggere la supply chain conoscendo le dipendenze, gestendo le dipendenze e monitorando la catena di approvvigionamento.

Sono stati appresi vari metodi forniti da NuGet e GitHub che sono attualmente disponibili per essere più efficaci nella visualizzazione, nella gestione e nel monitoraggio della supply chain.

Per altre informazioni sulla protezione del software mondiale, vedere The State of the Octoverse 2020 Security Report.For more information about securing the world's software, see The State of the Octoverse 2020 Security Report.