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

Pacchetti con vulnerabilità note

📦 Consumer di pacchetti | 📦🖊 Autore del pacchetto

.NET 8 e Visual Studio 17.8 hanno aggiunto NuGetAudit, che avvertirà i pacchetti diretti con vulnerabilità note durante il ripristino. .NET 9 e Visual Studio 17.12 hanno modificato l'impostazione predefinita per avvisare anche i pacchetti transitivi.

NuGetAudit richiede un'origine per fornire un database di vulnerabilità note, quindi se non si usa nuget.org come origine del pacchetto, è consigliabile aggiungerla come origine di controllo.

Quando NuGet avvisa l'utente, la vulnerabilità è nota pubblicamente. Gli utenti malintenzionati possono usare questa divulgazione pubblica per sviluppare attacchi per destinazioni che non hanno eseguito patch alle applicazioni. Pertanto, quando viene visualizzato un avviso che indica che un pacchetto usato dal progetto presenta una vulnerabilità nota, è consigliabile intervenire rapidamente.

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. È anche possibile usare il comando per comprendere perché dotnet nuget why i pacchetti transitivi (quelli non a cui fa riferimento direttamente il progetto) vengono inclusi nel grafico dei pacchetti del progetto.

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. Possono 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. NuGetAudit può segnalare le dipendenze vulnerabili note ed è abilitato per impostazione predefinita quando un'origine fornisce un database di vulnerabilità.

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

Usare le origini dei pacchetti attendibili. 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.

Proteggere i computer

Autorizzazioni della directory

📦 Consumer di pacchetti

In Windows e Mac e alcune distribuzioni Linux, le home directory dell'account utente sono private per impostazione predefinita. Tuttavia, alcune distribuzioni linux rendono leggibili le directory utente da altri account nello stesso computer per impostazione predefinita. Sono inoltre disponibili più opzioni di configurazione per reindirizzare la cartella dei pacchetti globali di NuGet e la cache HTTP a percorsi non predefiniti. È anche possibile creare soluzioni, progetti e repository all'esterno della home directory dell'utente.

Se si usano pacchetti non presenti in nuget.org, se un altro account nel computer può leggere i pacchetti globali o le directory della cache HTTP di NuGet o la directory di output della compilazione del progetto, questi pacchetti potrebbero essere divulgati agli utenti che non devono avere accesso a tali pacchetti.

In Linux dotnet nuget update source modificherà le autorizzazioni del file nuget.config per renderlo leggibile solo dal proprietario del file. Tuttavia, se si modifica il file nuget.config in qualsiasi altro modo e il file si trova in un percorso in cui altri account possono leggere il file, potrebbe esserci una divulgazione di informazioni sull'URL dell'origine del pacchetto o sulle credenziali dell'origine del pacchetto. È necessario assicurarsi che qualsiasi file nuget.config non possa essere letto da altri utenti dello stesso computer.

Soluzioni all'interno della directory di download

📦 Consumer di pacchetti

Prestare particolare attenzione se si lavora su soluzioni o progetti nella directory dei download. NuGet accumulerà le impostazioni da più file di configurazione e MSBuild in genere importerà Directory.Build.props, Directory.NuGet.props, Directory.Build.targets e potenzialmente altri file, da qualsiasi directory padre, fino alla radice del file system.

La cartella download ha un rischio aggiuntivo, poiché è in genere il percorso predefinito in cui i Web browser scaricherà i file da Internet

Agenti di compilazione

📦 Consumer di pacchetti

Gli agenti di compilazione (agenti CI) che non vengono reimpostati su uno stato iniziale dopo che ogni compilazione presenta più rischi che devono essere considerati.

Per informazioni sui modi sicuri per gestire le credenziali, vedere la documentazione sull'utilizzo di pacchetti da feed autenticati.

Per informazioni sulla modifica delle directory in cui NuGet archivia i dati, vedere la documentazione sulla gestione di pacchetti, cache e cartelle temporanee globali. Queste directory devono essere configurate in una directory che l'agente ci pulisce dopo ogni compilazione.

Si noti che tutti i pacchetti usati dal progetto potrebbero essere lasciati nella directory di output della compilazione del progetto. Se il progetto usa pacchetti da origini autenticate, altri utenti dello stesso agente CI potrebbero ottenere l'accesso non autorizzato agli assembly del pacchetto. Pertanto, è consigliabile pulire anche il repository alla fine della compilazione, anche quando la compilazione non riesce o viene annullata.

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.

Prendere in considerazione anche la possibilità di segnalare il noto al database di advisor di GitHub.

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.