Dela via

Granska paketberoenden för säkerhetsrisker

Om säkerhetsgranskningar

En säkerhetsgranskning för pakethanterare som NuGet är en process som innebär att analysera säkerheten för de paket som ingår i ett programvaruprojekt. Det handlar om att identifiera sårbarheter, utvärdera risker och göra rekommendationer för att förbättra säkerheten. Granskningen kan omfatta en granskning av själva paketen, samt eventuella beroenden och deras associerade risker. Målet med granskningen är att identifiera och minimera säkerhetsrisker som kan utnyttjas av angripare, till exempel kodinmatning eller skriptattacker mellan webbplatser.

Vi har också ett blogginlägg som beskriver vår rekommenderade metod för att vidta åtgärder när ett paket med en känd säkerhetsrisk visar sig användas av ditt projekt och verktyg för att få mer information.

Tillgänglighet av funktioner

NuGet (på engelska) .NET SDK Visual Studio Egenskap
5.9 .NET 5 SDK (5.0.200) Inte tillgänglig dotnet list package --vulnerable
6.8 .NET 8 SDK (8.0.100) Visual Studio 2022 17.8 NuGetAudit för PackageReference
6.10 Inte tillgänglig Visual Studio 2022 17.10 NuGetAudit för packages.config
6.11 .NET 8 SDK (8.0.400) Visual Studio 2022 17.11 NuGetAuditSuppress för PackageReference
6.12 .NET 9 SDK (9.0.100) Visual Studio 2022 17.12 Revidera källor. NuGetAuditSuppress för packages.config.

Köra en säkerhetsgranskning med restore

Kommandot restore körs automatiskt när du utför en vanlig paketåtgärd som att läsa in ett projekt för första gången, lägga till ett nytt paket, uppdatera en paketversion eller ta bort ett paket från projektet i din favorit-IDE. Dina beroenden kontrolleras mot en lista över kända säkerhetsrisker som tillhandahålls av dina granskningskällor.

  1. Gå till projekt- eller lösningskatalogen på kommandoraden.
  2. Kör restore med önskat verktyg (t.ex. dotnet, MSBuild, NuGet.exe, VisualStudio osv.).
  3. Granska varningarna och åtgärda kända säkerhetsrisker.

Konfigurera NuGet-granskning

Granskning kan konfigureras via MSBuild-egenskaper i en eller MSBuild-fil som utvärderas som en .csproj del av projektet. Vi rekommenderar att granskning konfigureras på lagringsplatsnivå.

MSBuild-egenskapen Förinställning Möjliga värden Noteringar
NuGetAudit-läge Se 1 nedan direct och all Om du bara vill granska beroenden på den översta nivån kan du ange värdet till direct. NuGetAuditMode gäller inte för packages.config projekt.
NuGetAuditLevel Låg low, moderate, highoch critical Den minsta allvarlighetsgrad som ska rapporteras. Om du vill se moderate, highoch critical rekommendationer (exkludera low) anger du värdet till moderate
NuGetAudit sann true och false Om du inte vill ta emot säkerhetsgranskningsrapporter kan du välja bort upplevelsen helt och hållet genom att ange värdet till false
  1. NuGetAuditMode har standardvärdet all när ett projekt riktar sig mot net10.0 eller högre. Annars NuGetAuditMode är standardvärdet direct. När ett projekt med flera mål, om något målramverk väljer all, använder granskning det här värdet för alla målramverk.

Granskningskällor

Återställning laddar ned en serverresursVulnerabilityInfo för att kontrollera listan över paket som varje projekt använder. Listan över källor definieras av -elementet auditSources i NuGet.Config och varning nu1905 genereras om någon av granskningskällorna inte tillhandahåller någon sårbarhetsinformation. Om auditSources inte har definierats eller om källor inte har lagts till, då kommer packageSources att användas och varningen NU1905 undertrycks.

Eftersom en vanlig åtgärd för paketersättningsattacker är att använda en enda paketkälla som överförs från nuget.org, så att NuGet inte är konfigurerat att använda nuget.org som paketkälla, kan granskningskällor användas för att använda nuget.org (eller någon annan källa som tillhandahåller sårbarhetsinformation) utan att även använda den som paketkälla.

Datakällan för nuget.org:s sårbarhetsdatabas är GitHub Advisory Database. Observera att V2-protokollet är inaktuellt, så om din nuget.config fortfarande använder V2-slutpunkten måste du migrera till V3-slutpunkten.

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

Granskningskällor är tillgängliga från NuGet 6.12, .NET 9.0.100 SDK och Visual Studio 2022 17.12. Före den här versionen använder NuGet Audit endast paketkällor för att ladda ned sårbarhetsinformation. Granskningskällor används inte av dotnet list package --vulnerable just nu.

Exklusive varningar

Du kan välja att undanta specifika rekommendationer från granskningsrapporten genom att lägga till ett nytt NuGetAuditSuppress MSBuild-objekt för varje rådgivning. Definiera ett NuGetAuditSuppress objekt med Include= metadata inställda på den rådgivande URL som du vill utelämna.

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

På samma sätt som andra NuGet-granskningskonfigurationsegenskaper NuGetAuditSuppress kan objekt definieras på projekt- eller lagringsplatsnivå.

NuGetAuditSuppress är tillgängligt för PackageReference-projekt från NuGet 6.11, Visual Studio 17.11 och .NET 8.0.400 SDK. Den är tillgänglig för packages.config från Visual Studio 17.12 och NuGet 6.12.

Varningskoder

Varningskod Förnuft
NU1900 Det gick inte att kommunicera med paketkällan när sårbarhetsinformation skulle hämtas.
NU1901 Paket med låg allvarlighetsgrad har identifierats
NU1902 Paket med måttlig allvarlighetsgrad identifierad
NU1903 Paket med hög allvarlighetsgrad identifierad
NU1904 Paket med kritisk allvarlighetsgrad har identifierats
NU1905 En granskningskälla tillhandahåller ingen sårbarhetsdatabas

Du kan anpassa din version för att behandla dessa varningar som fel för att: behandla varningar som fel eller inte behandla varningar som fel. Om du till exempel redan använder <TreatWarningsAsErrors> för att behandla alla varningar (C#, NuGet, MSBuild osv.) som fel kan du använda <WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> för att förhindra att säkerhetsrisker som identifieras i framtiden bryter mot bygget. Alternativt kan du använda <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors> om du vill behandla låga och måttliga sårbarheter som varningar, men höga och kritiska sårbarheter som fel, och du inte använder TreatWarningsAsErrors.

Anmärkning

MSBuild-egenskaper för allvarlighetsgrad för meddelanden, till exempel NoWarn och TreatWarningsAsErrors stöds inte för packages.config projekt.

Se till att återställ granskade projekt

NuGet i MSBuild 17.13 och .NET 9.0.200 har lagt till utdataegenskaper RestoreProjectCount, RestoreSkippedCount och RestoreProjectsAuditedCount på återställningsuppgiften. Detta kan användas för att säkerställa att granskningen genomfördes under återställningen. Observera att dessa utdataegenskaper inte är tillgängliga vid återställning av statiska diagram.

Eftersom MSBuild är ett skriptspråk kan detta uppnås på flera olika sätt, men har också samma begränsningar som MSBuild har. Ett exempel är att skapa en fil Directory.Solution.targets i samma katalog som din lösningsfil, vars innehåll har ett mål som liknar följande. Observera att Directory.Build.props används ofta, men importeras av projekt. NuGets återställningsmål och uppgift körs dock på lösningsnivå, så måste finnas i MSBuilds lösningsextensibilitetsfil, inte projekt-/byggfilen.

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

Beroende på ditt scenario kan du vilja använda villkoret '$(RestoreProjectCount)' != '$([MSBuild::Add($(RestoreProjectsAuditedCount), $(RestoreSkippedCount))' i felmeddelandet för att ta hänsyn till projekt vars återställning hoppades över eftersom de redan var uppdaterade. På samma sätt bör du tänka på om du vill att det här felet ska inträffa överallt, eller bara i CI-pipelines, och vilka miljövariabler som definieras i din CI-miljö och integrera detta i målets villkor. Eftersom MSBuild är ett skriptspråk kan du använda någon av dess funktioner för att anpassa lagringsplatsen hur du vill. Att visa MSBuilds metaproj och binlogs är användbara för att utveckla och felsöka mål på lösningsnivån.

dotnet list package --vulnerable

När ett projekt har återställts framgångsrikt dotnet list package har du ett --vulnerable argument för att filtrera paketen baserat på vilka paket som har kända sårbarheter. Observera att det --include-transitive inte är standard, så bör inkluderas.

Åtgärder när paket med kända sårbarheter rapporteras

Vi har också ett blogginlägg som beskriver vår rekommenderade metod för att vidta åtgärder när ett paket med en känd säkerhetsrisk visar sig användas av ditt projekt och verktyg för att få mer information.

Säkerhetsrisker som hittas med uppdateringar

Om säkerhetsrisker hittas och uppdateringar är tillgängliga för paketet kan du antingen:

  • Redigera .csproj eller en annan plats för paketversion (Directory.Packages.props) med en nyare version som innehåller en säkerhetskorrigering.
  • Använd Användargränssnittet för NuGet-pakethanteraren i Visual Studio för att uppdatera det enskilda paketet.
  • dotnet add package Kör kommandot med respektive paket-ID för att uppdatera till den senaste versionen.

Transitiva paket

Om det finns en känd säkerhetsrisk i ett toppnivåpakets transitiva beroenden har du följande alternativ:

  • Lägg till den fasta paketversionen som en direkt paketreferens. Not: Se till att ta bort den här referensen när en ny paketversionsuppdatering blir tillgänglig och se till att behålla de definierade attributen för det förväntade beteendet.
  • Använd Central Package Management med funktionen för transitiv fästning.
  • Ignorera rekommendationen tills den kan åtgärdas.
  • Skapa ett ärende i det högsta paketets ärendehanterare för att begära en uppdatering.

Säkerhetsrisker hittades utan uppdateringar

Om det finns en känd säkerhetsrisk i ett paket utan en säkerhetskorrigering kan du göra följande.

  • Sök efter eventuella förmildrande faktorer som beskrivs i den rådgivande rapporten.
  • Använd ett föreslaget paket om paketet har markerats som inaktuellt eller har avbrutits.
  • Om paketet är öppen källkod kan du överväga att bidra med en korrigering.
  • Öppna ett problem i paketets problemspårare.

Kontrollera om det finns förmildrande faktorer

Granska säkerhetsrådgivaren efter eventuella förmildrande faktorer som kan göra att du kan fortsätta använda paketet med säkerhetsrisken. Säkerhetsrisken kanske bara finns när koden används i ett specifikt ramverk, operativsystem eller en särskild funktion anropas.

Använda ett föreslaget paket

Om en säkerhetsrekommendering rapporteras för det paket du använder och paketet har markerats som inaktuellt eller verkar ha avbrutits kan du överväga att använda alla föreslagna alternativa paket som paketförfattaren har deklarerat eller ett paket som består av liknande funktioner som underhålls.

Bidra med en korrigering

Om det inte finns någon korrigering för säkerhetsrådgivningen kan du föreslå ändringar som åtgärdar säkerhetsrisken i en pull-begäran på paketets lagringsplats med öppen källkod eller kontakta författaren via Contact owners avsnittet på sidan NuGet.org paketinformation.

Öppna ett problem

Om du inte vill åtgärda säkerhetsrisken eller inte kan uppdatera eller ersätta paketet öppnar du ett problem i paketets problemspårare eller önskad kontaktmetod. På NuGet.org kan du gå till sidan med paketinformation och klicka på Report package det som hjälper dig att komma i kontakt med författaren.

Inga säkerhetsrisker hittades

Om inga säkerhetsrisker hittas innebär det att paket med kända säkerhetsrisker inte hittades i paketdiagrammet för tillfället som du kontrollerade. Eftersom den rådgivande databasen kan uppdateras när som helst rekommenderar vi att du regelbundet kontrollerar dina dotnet restore utdata och säkerställer samma sak i din kontinuerliga integreringsprocess.

Sammanfattning

Säkerhetsgranskningsfunktioner är avgörande för att upprätthålla säkerheten och integriteten i programvaruprojekt. De här funktionerna ger dig ytterligare ett lager av skydd mot säkerhetsrisker och säkerställer att du kan använda paket med öppen källkod med säkerhet.