Controllo delle dipendenze dei pacchetti per le vulnerabilità di sicurezza

Informazioni sui controlli di sicurezza

Un controllo di sicurezza per gli strumenti di gestione pacchetti come NuGet è un processo che prevede l'analisi della sicurezza dei pacchetti inclusi in un progetto software. Ciò implica l'identificazione delle vulnerabilità, la valutazione dei rischi e la creazione di raccomandazioni per migliorare la sicurezza. Il controllo può includere una revisione dei pacchetti stessi, nonché eventuali dipendenze e i relativi rischi associati. L'obiettivo del controllo è identificare e attenuare eventuali vulnerabilità di sicurezza che potrebbero essere sfruttate da utenti malintenzionati, ad esempio attacchi di inserimento di codice o scripting intersito.

Disponibilità di funzionalità

NuGet	.NET SDK	Visual Studio	Funzionalità
5.9	.NET 5 SDK (5.0.200)	N/D	dotnet list package --vulnerable
6.8	.NET 8 SDK (8.0.100)	Visual Studio 2022 17.8	NuGetAudit per PackageReference
6.10	N/D	Visual Studio 2022 17.10	NuGetAudit per packages.config
6.11	.NET 8 SDK (8.0.400)	Visual Studio 2022 17.11	NuGetAuditSuppress per PackageReference
6.12	.NET 9 SDK (9.0.100)	Visual Studio 2022 17.12	Controlla le origini. NuGetAuditSuppress per packages.config.
7.0	.NET 10 SDK (10.0.100)	Visual Studio 2026	Modifiche predefinite di NuGetAuditMode per .NET 10. dotnet package update --vulnerable

Esecuzione di un controllo di sicurezza con restore

Il restore comando viene eseguito automaticamente quando si esegue un'operazione di pacchetto comune, ad esempio il caricamento di un progetto per la prima volta, l'aggiunta di un nuovo pacchetto, l'aggiornamento di una versione del pacchetto o la rimozione di un pacchetto dal progetto nell'IDE preferito. Le dipendenze vengono controllate rispetto a un elenco di vulnerabilità note fornite dalle origini di controllo.

1. Nella riga di comando passare alla directory del progetto o della soluzione.
2. Eseguire restore usando gli strumenti preferiti, ad esempio dotnet, MSBuild, NuGet.exe, VisualStudio e così via.
3. Esaminare gli avvisi e risolvere le vulnerabilità di sicurezza note.

Configurazione del controllo NuGet

Il controllo può essere configurato tramite le proprietà MSBuild in un .csproj file o MSBuild valutato come parte del progetto. È consigliabile configurare il controllo a livello di repository.

Proprietà MSBuild	Predefiniti	Possibili valori	Note
NuGetAuditMode	Vedere 1 di seguito	direct e all	Se si desidera controllare solo le dipendenze di primo livello, è possibile impostare il valore su direct. NuGetAuditMode non è applicabile ai progetti packages.config.
NuGetAuditLevel	basso	low, moderate, high e critical	Livello di gravità minimo da segnalare. Se si desidera visualizzare moderategli avvisi , highe critical (escludere low), impostare il valore su moderate
NuGetAudit	vero	true e false	Se si desidera non ricevere report di controllo della sicurezza, è possibile rifiutare esplicitamente l'esperienza impostando il valore su false

1. NuGetAuditMode il valore predefinito è all quando un progetto è destinato net10.0 o superiore. Altrimenti NuGetAuditMode imposta il valore predefinito su direct. Quando un progetto ha più destinazioni, se uno qualsiasi dei framework di destinazione seleziona all, la verifica utilizzerà questo valore per tutti i framework di destinazione.

Controlla origini

Il ripristino scarica la risorsaVulnerabilityInfo un server per verificare l'elenco dei pacchetti usati da ogni progetto. L'elenco delle origini è definito dall'elemento auditSources e viene generato l'avviso NU1905 se una delle origini di controllo non fornisce informazioni sulla vulnerabilità. Se auditSources non è definito o viene cancellato senza aggiungere origini, packageSources verrà usato e verrà eliminato l'avviso NU1905.

Poiché una mitigazione comune per gli attacchi di sostituzione dei pacchetti consiste nell'usare un'unica origine di pacchetto da nuget.org, in modo che NuGet non sia configurato per l'uso di nuget.org come origine del pacchetto, le origini di controllo possono essere usate per usare nuget.org (o qualsiasi altra origine che fornisce informazioni sulla vulnerabilità) senza usarla anche come origine del pacchetto.

L'origine dati per il database di vulnerabilità di nuget.org è Database consultivo GitHub. Si noti che il protocollo V2 è deprecato, quindi se nuget.config usa ancora l'endpoint V2, è necessario eseguire la migrazione all'endpoint V3.

<configuration>
    <auditSources>
        <clear />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </auditSources>
</configuration>

Nota: la tabella seguente elenca le funzionalità che supportano le origini di controllo.

Introdotto in	Funzionalità che supportano le origini di controllo
NuGet 6.12, .NET 9.0.100 SDK e Visual Studio 2022 17.12	Ripristina
NuGet 6.14, .NET 9.0.300 SDK	dotnet package list --vulnerable
NuGet 7.0 e Visual Studio 2026	Supporto di AuditSources NuGet nell'interfaccia utente di Gestione pacchetti di Visual Studio

Codici di avviso

Codice di avviso	Motivo
NU1900	Errore durante la comunicazione con l'origine del pacchetto, durante il recupero delle informazioni sulla vulnerabilità.
NU1901	Pacchetto con gravità bassa rilevata
NU1902	Pacchetto con gravità moderata rilevata
NU1903	Pacchetto con gravità elevata rilevata
NU1904	Pacchetto con gravità critica rilevata
NU1905	Un'origine di controllo non fornisce un database di vulnerabilità

È possibile personalizzare la compilazione per considerare questi avvisi come errori per considerare gli avvisi come errori o considerare gli avvisi non come errori. Ad esempio, se si usano <TreatWarningsAsErrors> già per considerare tutti gli avvisi (C#, NuGet, MSBuild e così via) come errori, è possibile usare <WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> per evitare che le vulnerabilità individuate in futuro causano interruzioni della compilazione. In alternativa, se si desidera mantenere le vulnerabilità basse e moderate come avvisi, ma considerare le vulnerabilità elevate e critiche come errori e non si usa TreatWarningsAsErrors, è possibile usare <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors>.

Nota

Le proprietà di MSBuild per la gravità del messaggio, NoWarn ad esempio e TreatWarningsAsErrors non sono supportate per i progetti packages.config.

Esclusione di avvisi

È possibile escludere gli avvisi aggiungendo un nuovo NuGetAuditSuppress elemento MSBuild per ogni avviso. Definire un NuGetAuditSuppress elemento con i Include= metadati impostati sull'URL di avviso da eliminare.

<ItemGroup>
    <NuGetAuditSuppress Include="https://github.com/advisories/XXXX" />
</ItemGroup>

Analogamente alle altre proprietà di configurazione del controllo NuGet, NuGetAuditSuppress gli elementi possono essere definiti a livello di progetto o repository.

NuGetAuditSuppress è disponibile per i progetti PackageReference a partire da NuGet 6.11, Visual Studio 17.11 e .NET 8.0.400 SDK. È disponibile per packages.config da Visual Studio 17.12 e NuGet 6.12.

Quando escludere avvisi

Negli scenari in cui è stato analizzato un avviso specifico e si è determinato che non si applica allo scenario oppure si è a proprio agio con i rischi che impone, è possibile scegliere di escludere avvisi specifici dal report di controllo. Si noti che questo sopprimerà completamente gli avvisi, anche per i pacchetti che condividono l'avviso che potrebbe non far parte del tuo progetto. NuGetAuditSuppress deve essere considerata un'ultima risorsa per la gestione degli avvisi.

Azioni quando vengono segnalati pacchetti con vulnerabilità note

Ricevere un avviso sui pacchetti con vulnerabilità note è solo parte del processo. Una volta individuato, è necessario intervenire per rimuovere la potenziale vulnerabilità dalla soluzione.

Il caso più semplice è quando un pacchetto a cui si fa riferimento direttamente presenta la vulnerabilità nota. In questo caso, aggiornare la versione del pacchetto a una che corregge la vulnerabilità.

Le vulnerabilità del pacchetto possono essere segnalate in riferimenti diretti e transitivi al pacchetto. L'azione che si esegue per risolvere può essere diversa a causa di questo.

Vulnerabilità di sicurezza rilevate con gli aggiornamenti

Se vengono rilevate vulnerabilità di sicurezza e gli aggiornamenti sono disponibili per il pacchetto, è possibile eseguire una delle operazioni seguenti:

• Modificare il .csproj percorsoDirectory.Packages.props della versione del pacchetto o altro () con una versione più recente contenente una correzione di sicurezza.
• Usare l'interfaccia utente di Gestione pacchetti NuGet in Visual Studio per aggiornare il singolo pacchetto.
• Eseguire il dotnet package update --vulnerable comando per aggiornare tutti i pacchetti vulnerabili in un progetto alla prima versione senza vulnerabilità note.
• Eseguire i comandi dotnet package update o dotnet package add con il rispettivo ID pacchetto per aggiornare alla versione più recente. Usare dotnet add package quando si usa .NET 9 o versioni precedenti.
• Usare il server MCP (Model Context Protocol) NuGet che ha la possibilità di aggiornare i pacchetti nel progetto alle versioni che risolvono le vulnerabilità note. Per altre informazioni , vedere Correzione delle vulnerabilità dei pacchetti .

Pacchetti transitivi

Spesso una vulnerabilità si trova in una dipendenza transitiva. È consigliabile preferire gli aggiornamenti ai pacchetti "più vicini" ai riferimenti diretti. Tuttavia, non c'è nulla di sbagliato con l'aggiornamento del pacchetto con vulnerabilità note.

Si supponga, ad esempio, che il progetto faccia riferimento al pacchetto A. Il pacchetto A ha una dipendenza dal pacchetto B, che a sua volta ha una dipendenza dal pacchetto C. In questo esempio si considererà che il pacchetto C versione 1.0.0 presenta una vulnerabilità nota, risolta nella versione 2.0.0. È consigliabile provare prima di tutto ad aggiornare il pacchetto A. Se questo non risolve l'avviso di controllo, provare ad aggiornare il pacchetto B. Se questo non risolve l'avviso di controllo, aggiornare direttamente C. Per facilitare questo problema, è necessario trovare il percorso transitivo del pacchetto.

In sintesi, se esiste una vulnerabilità nota nelle dipendenze transitive di un pacchetto di primo livello, sono disponibili queste opzioni:

• Controllare se il pacchetto di primo livello contiene un aggiornamento che non presenta una vulnerabilità transitiva e aggiornare tale aggiornamento.
• Aggiornare il pacchetto più vicino ai riferimenti diretti che non fanno riferimento a una vulnerabilità.
• Aggiungere la versione fissa del pacchetto come riferimento diretto al pacchetto. Nota: assicurarsi di rimuovere questo riferimento quando diventa disponibile un nuovo aggiornamento della versione del pacchetto e assicurarsi di mantenere gli attributi definiti per il comportamento previsto.
• Usare Gestione pacchetti centrali con la funzionalità di aggiunta transitiva. Si noti che se si inserisce il progetto nel proprio pacchetto per condividerlo con altri utenti, CPM con l'aggiunta transitiva causerà la creazione di dipendenze dei pacchetti, anche se il progetto non chiama direttamente le API su tale pacchetto.
• Eliminare l'avviso fino a quando non può essere risolto.
• Inviare un problema nel tracker del pacchetto di primo livello per richiedere un aggiornamento.

Ricerca del percorso transitivo del pacchetto

Esistono diversi modi per trovare il percorso del pacchetto. Quale metodo si preferisce dipende da quali strumenti si usano normalmente durante lo sviluppo.

dotnet nuget perché

Nella riga di comando è possibile usare il comando per comprendere perché dotnet nuget why i pacchetti transitivi vengono inclusi nel grafico dei pacchetti del progetto.

Esplora soluzioni di Visual Studio

I progetti in stile SDK forniscono anche il grafico completo del pacchetto nel nodo Dipendenze del progetto. È anche ricercabile! Espandere le opzioni di ricerca e abilitare "cerca file esterni".

Cercare il nome del pacchetto e verranno visualizzate tutte le istanze nel nodo Dipendenze di ogni progetto.

Interfaccia utente di Gestione pacchetti NuGet di Visual Studio

Quando si esamina la scheda Installato nell'interfaccia utente di Gestione pacchetti di Visual Studio, quando il progetto usa PackageReference per la gestione dei pacchetti, verranno visualizzati sia i pacchetti diretti che transitivi. Attualmente, questo avviene solo quando si gestiscono i pacchetti per un progetto, non per la soluzione.

Quando passi col mouse sopra un pacchetto nell'elenco dei pacchetti, il tooltip mostrerà il nome di un pacchetto diretto che ha causato l'inclusione del pacchetto transitivo nel progetto.

Vulnerabilità di sicurezza rilevate senza aggiornamenti

Nel caso in cui esista una vulnerabilità nota in un pacchetto senza una correzione di sicurezza, è possibile eseguire le operazioni seguenti.

• Verificare la presenza di eventuali fattori di mitigazione descritti nel report consultivo.
• Usare un pacchetto suggerito se il pacchetto è contrassegnato come deprecato o viene abbandonato.
• Se il pacchetto è open source, prendere in considerazione la possibilità di contribuire a una correzione.
• Aprire un problema nello strumento di rilevamento dei problemi del pacchetto.

Verificare la presenza di fattori di mitigazione

Esaminare l'assistente alla sicurezza per eventuali fattori di mitigazione che potrebbero consentire di continuare a usare il pacchetto con la vulnerabilità. La vulnerabilità può esistere solo quando il codice viene usato in un framework specifico, in un sistema operativo o viene chiamata una funzione speciale.

Usare un pacchetto suggerito

Nel caso in cui venga segnalato un avviso di sicurezza per il pacchetto in uso e il pacchetto è contrassegnato come deprecato o sembra abbandonato, è consigliabile usare qualsiasi pacchetto alternativo suggerito dichiarato dall'autore del pacchetto o un pacchetto che comprende funzionalità simili mantenute.

Contribuire a una correzione

Se non esiste una correzione per l'avviso di sicurezza, è consigliabile suggerire modifiche che risolano la vulnerabilità in una richiesta pull nel repository open source del pacchetto o contattare l'autore tramite la Contact owners sezione nella pagina dei dettagli del pacchetto NuGet.org.

Aprire un problema

Se non si vuole correggere la vulnerabilità o non è possibile aggiornare o sostituire il pacchetto, aprire un problema nel rilevatore dei problemi del pacchetto o nel metodo di contatto preferito. In NuGet.org è possibile passare alla pagina dei dettagli del pacchetto e fare clic su Report package quale guida per entrare in contatto con l'autore.

Nessuna vulnerabilità di sicurezza trovata

Se non vengono rilevate vulnerabilità di sicurezza, significa che i pacchetti con vulnerabilità note non sono stati trovati nel grafico del pacchetto al momento corrente della verifica. Poiché il database consultivo può essere aggiornato in qualsiasi momento, è consigliabile controllare dotnet restore regolarmente l'output e garantire lo stesso nel processo di integrazione continua.

Esecuzione del controllo NuGet in CI

Separazione degli errori dagli avvisi con una pipeline di controllo dedicata

È possibile usare le istruzioni condizionali di MSBuild per configurare una pipeline CI dedicata per l'esecuzione di controlli, senza avvisi di controllo considerati come errori in altre pipeline o nelle build locali. A seconda del sistema di integrazione continua e dei processi del team, è possibile che le esecuzioni non riuscite della pipeline di controllo siano inviate al team tramite email, oppure che sia presente una dashboard su cui è possibile visualizzare un badge dell'esecuzione più recente della pipeline.

Come molti aspetti della programmazione, esistono diversi modi per ottenere il risultato. Un'opzione consiste nel considerare gli avvisi di controllo NuGet come errori solo in una pipeline di controllo.

<PropertyGroup>
  <NuGetAuditCodes>NU1900;NU1901;NU1902;NU1903;NU1904;NU1905</NuGetAuditCodes>
  <WarningsAsErrors Condition=" '$(AuditPipeline)' == 'true' ">$(WarningsAsErrors);$(NuGetAuditCodes)</WarningsAsErrors>
  <WarningsNotAsErrors Condition=" '$(AuditPipeline)' != 'true' ">$(WarningsNotAsErrors);$(NuGetAuditCodes)</WarningsNotAsErrors>
</PropertyGroup>

Quindi, nella pipeline eseguire il ripristino specificando la proprietà usata dalla condizione. Ad esempio, usando la sintassi di GitHub Actions:

- name: Restore with NuGet Auditing
  run: dotnet restore -p:AuditPipeline=true

Il nome AuditPipeline della proprietà è solo un esempio ed è possibile personalizzarlo nel modo desiderato, purché il nome sia lo stesso sia nella condizione MSBuild che nella riga di comando. MSBuild usa anche le variabili di ambiente durante la lettura di una proprietà non ancora definita, pertanto una variabile di ambiente è un'alternativa al parametro della riga di comando.

Se si usano condizioni per causare in modo selettivo che gli avvisi di controllo NuGet abbiano esito negativo, è possibile disporre di una pipeline dedicata per controllare la presenza di vulnerabilità note nei pacchetti, impedendo al contempo ai nuovi avvisi di sicurezza di bloccare le correzioni di bug in momenti scomodi. Mantenere abilitati gli avvisi di controllo NuGet per le compilazioni locali consente agli sviluppatori di ottenere una notifica non bloccanti sui nuovi avvisi di sicurezza e può incoraggiare l'aggiornamento delle versioni dei pacchetti per correggere le vulnerabilità più rapidamente rispetto all'attesa di un utente per controllare lo stato della pipeline di controllo.

Verificare che i progetti controllati vengano ripristinati

NuGet in MSBuild 17.13 e .NET 9.0.200 hanno aggiunto le proprietà di output RestoreProjectCount, RestoreSkippedCount e RestoreProjectsAuditedCount nell'attività di ripristino. Questo può essere utilizzato per garantire che la verifica venga eseguita durante un ripristino. Si noti che queste proprietà di output non sono disponibili con il ripristino statico del grafo.

Poiché MSBuild è un linguaggio di scripting, ciò può essere realizzato in diversi modi, ma presenta anche le stesse restrizioni di MSBuild. Un esempio consiste nel creare un file Directory.Solution.targets nella stessa directory del file della soluzione, il cui contenuto ha una destinazione simile alla seguente. Si noti che Directory.Build.props viene comunemente usato, ma viene importato dai progetti. Tuttavia, la destinazione e l'attività di ripristino di NuGet vengono eseguite a livello di soluzione, quindi deve trovarsi nel file di estendibilità della soluzione di MSBuild, non nel file di progetto/compilazione.

<Project>
    <Target Name="AssertRestoreTaskOutputProperties"
            AfterTargets="Restore"
            Condition="'$(CI)' == 'true'">
        <Error
            Condition="'$(RestoreProjectsAuditedCount)' != '$(RestoreProjectCount)'"
            Text=""Restore did not audit every project in the solution. Expected: $(RestoreProjectCount) Found: $(RestoreProjectsAuditedCount)"" />
    </Target>
</Project>

A seconda del caso d'uso, è possibile utilizzare la condizione '$(RestoreProjectCount)' != '$([MSBuild::Add($(RestoreProjectsAuditedCount), $(RestoreSkippedCount))' nel messaggio di errore, per gestire i progetti restaurati ignorati perché erano già aggiornati. Analogamente, considera se desideri che questo errore si verifichi ovunque oppure solo nelle pipeline CI (Continuous Integration), e quali variabili di ambiente sono definite nel tuo ambiente CI; includi queste considerazioni nella condizione della destinazione. Anche in questo caso, poiché MSBuild è un linguaggio di scripting, è possibile usare una delle relative funzionalità per personalizzare il repository desiderato. La visualizzazione dei metaproj e dei binlogdi MSBuild è utile per sviluppare e risolvere i problemi relativi alle destinazioni a livello di soluzione.

dotnet list package --vulnerable

dotnet list package ha un --vulnerable argomento per filtrare i pacchetti in base ai pacchetti con vulnerabilità note. Si noti che --include-transitive non è predefinito, quindi deve essere incluso.