Condividi tramite

Controllo delle dipendenze dei pacchetti per le vulnerabilità di sicurezza

  • Articolo

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.

È disponibile anche un post di blog che illustra il metodo consigliato per intervenire quando viene rilevato che un pacchetto con una vulnerabilità nota viene usato dal progetto e gli strumenti per ottenere altre informazioni.

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.

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 all (1) direct e all Se si desidera controllare sia le dipendenze di primo livello che le dipendenze transitive, è possibile impostare il valore su all. NuGetAuditMode non è applicabile ai progetti packages.config
NuGetAuditLevel low 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 true 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 è stato direct predefinito quando è stato introdotto in .NET 8.0.100 SDK e VS 17.8. In .NET 9.0.100 SDK e VS 17.12 il valore predefinito è stato modificato in all.

Controlla origini

Il ripristino scarica la risorsa di VulnerabilityInfo un server per verificare l'elenco dei pacchetti usati da ogni progetto. L'elenco delle origini è definito dall'elemento in NuGet.Config e viene generato l'avviso auditSources 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>

Le origini di controllo sono disponibili in NuGet 6.12, .NET 9.0.100 SDK e Visual Studio 2022 17.12. Prima di questa versione, NuGet Audit userà solo le origini dei pacchetti per scaricare le informazioni sulla vulnerabilità. Le origini di controllo non vengono usate in dotnet list package --vulnerable questo momento.

Esclusione di avvisi

È possibile scegliere di escludere avvisi specifici dal report di controllo 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.

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>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>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.

dotnet list package --vulnerable

Una volta ripristinato correttamente un progetto, dotnet list package ha un --vulnerable argomento per filtrare i pacchetti in base ai pacchetti in cui sono presenti vulnerabilità note. Si noti che --include-transitive non è predefinito, quindi deve essere incluso

Azioni quando vengono segnalati pacchetti con vulnerabilità note

È disponibile anche un post di blog che illustra il metodo consigliato per intervenire quando viene rilevato che un pacchetto con una vulnerabilità nota viene usato dal progetto e gli strumenti per ottenere altre informazioni.

Vulnerabilità di sicurezza rilevate con gli aggiornamenti

Se vengono rilevate vulnerabilità di sicurezza e gli aggiornamenti sono disponibili per il pacchetto, è possibile:

  • 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 add package comando con il rispettivo ID pacchetto per eseguire l'aggiornamento alla versione più recente.

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.

Riepilogo

Le funzionalità di controllo della sicurezza sono fondamentali per mantenere la sicurezza e l'integrità dei progetti software. Queste funzionalità offrono un ulteriore livello di protezione dalle vulnerabilità di sicurezza e garantisce che sia possibile usare pacchetti open source con sicurezza.