Afhankelijkheden van het controlepakket voor beveiligingsproblemen

Over beveiligingscontroles

Een beveiligingscontrole voor pakketbeheerders zoals NuGet is een proces waarbij de beveiliging wordt geanalyseerd van de pakketten die zijn opgenomen in een softwareproject. Dit omvat het identificeren van beveiligingsproblemen, het evalueren van risico's en het doen van aanbevelingen voor het verbeteren van de beveiliging. De controle kan een beoordeling van de pakketten zelf bevatten, evenals eventuele afhankelijkheden en de bijbehorende risico's. Het doel van de controle is om beveiligingsproblemen te identificeren en te beperken die kunnen worden misbruikt door aanvallers, zoals code-injectie of scriptaanvallen op meerdere sites.

Beschikbaarheid van functies

Een beveiligingscontrole uitvoeren met restore

De opdracht restore wordt automatisch uitgevoerd wanneer u een algemene pakketbewerking uitvoert, zoals het voor het eerst laden van een project, het toevoegen van een nieuw pakket, het bijwerken van een pakketversie of het verwijderen van een pakket uit uw project in uw favoriete IDE. Uw afhankelijkheden worden gecontroleerd op basis van een lijst met bekende beveiligingsproblemen die worden geleverd door uw auditbronnen.

1. Navigeer in de commando-interface naar uw project- of oplossingsmap.
2. Voer restore uit met behulp van uw favoriete hulpprogramma's (bijvoorbeeld dotnet, MSBuild, NuGet.exe, VisualStudio, enzovoort).
3. Bekijk de waarschuwingen en los de bekende beveiligingsproblemen op.

Configureren van NuGet Audit

Controle kan worden geconfigureerd via MSBuild-eigenschappen in een .csproj- of MSBuild-bestand dat wordt geëvalueerd als onderdeel van uw project. U wordt aangeraden de controle op opslagplaatsniveau te configureren.

1. NuGetAuditMode is standaard all wanneer een project gericht is op net10.0 of hoger. Anders NuGetAuditMode wordt standaard ingesteld op direct. Wanneer een project meerdere doelen aanpakt en een van de doelframeworks all selecteert, zal de audit deze waarde voor alle doelframeworks gebruiken.

Bronnen Auditen

Met herstellen wordt de VulnerabilityInfo-bron van een server gedownload om deze te vergelijken met de lijst van pakketten die door elk project worden gebruikt. De lijst met bronnen wordt gedefinieerd door het element auditSources in NuGet.Configen waarschuwing NU1905 wordt gegenereerd als een van de controlebronnen geen kwetsbaarheidsinformatie bevat. Als auditSources niet is gedefinieerd of wordt gewist zonder bronnen toe te voegen, wordt packageSources gebruikt en wordt waarschuwing NU1905 onderdrukt.

Aangezien een veelvoorkomende beperking voor pakketvervangingsaanvallen is om één pakketbron te gebruiken die upstreams van nuget.org, zodat NuGet niet is geconfigureerd voor gebruik van nuget.org als pakketbron, kunnen auditbronnen worden gebruikt om nuget.org (of een andere bron die informatie over beveiligingsproblemen levert) te gebruiken zonder deze ook als pakketbron te gebruiken.

De gegevensbron voor de beveiligingsdatabase van nuget.org is GitHub Advisory Database. Houd er rekening mee dat het V2-protocol is afgeschaft, dus als uw nuget.config nog steeds het V2-eindpunt gebruikt, moet u migreren naar het V3-eindpunt.

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

Opmerking: De onderstaande tabel bevat functies die ondersteuning bieden voor auditbronnen.

Waarschuwingscodes

U kunt uw build aanpassen om deze waarschuwingen te behandelen als fouten om waarschuwingen te als fouten te behandelen of waarschuwingen niet als fouten te behandelen. Als u bijvoorbeeld al <TreatWarningsAsErrors> gebruikt om alle waarschuwingen (C#, NuGet, MSBuild, enzovoort) als fouten te behandelen, kunt u <WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> gebruiken om te voorkomen dat beveiligingsproblemen die in de toekomst zijn gedetecteerd, uw build breken. U kunt ook, als u lage en gemiddelde beveiligingsproblemen wilt behouden als waarschuwingen, maar hoge en kritieke beveiligingsproblemen als fouten behandelen en u geen TreatWarningsAsErrorsgebruikt, kunt u <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors>gebruiken.

Adviezen uitsluiten

U kunt adviezen uitsluiten door een nieuw NuGetAuditSuppress MSBuild-item toe te voegen voor elk advies. Definieer een NuGetAuditSuppress item met de Include= metagegevens die zijn ingesteld op de advies-URL die u wilt onderdrukken.

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

Net als bij de andere Eigenschappen van de NuGet-controleconfiguratie kunnen NuGetAuditSuppress items worden gedefinieerd op project- of opslagplaatsniveau.

NuGetAuditSuppress is beschikbaar voor PackageReference-projecten vanaf NuGet 6.11, Visual Studio 17.11 en de .NET 8.0.400 SDK. Het is beschikbaar voor packages.config vanuit Visual Studio 17.12 en NuGet 6.12.

Wanneer advies moet worden uitgesloten

In scenario's waarin u een specifiek advies hebt geanalyseerd en hebt vastgesteld dat dit niet van toepassing is op uw scenario, of u vertrouwd bent met de risico's die het oplegt, kunt u ervoor kiezen om specifieke adviezen uit te sluiten van het auditrapport. Houd er rekening mee dat dit de adviezen volledig onderdrukt, zelfs voor pakketten die het advies delen dat mogelijk geen deel uitmaakt van uw project. NuGetAuditSuppress moet als laatste redmiddel worden beschouwd voor het beheren van adviezen.

Acties wanneer pakketten met bekende beveiligingsproblemen worden gerapporteerd

Het krijgen van een waarschuwing over pakketten met bekende beveiligingsproblemen maakt slechts deel uit van het proces. Nadat de oplossing is gedetecteerd, moet er actie worden ondernomen om het potentiële beveiligingsprobleem uit uw oplossing te verwijderen.

De eenvoudigste situatie is wanneer een pakket waarnaar u verwijst rechtstreeks het bekende beveiligingsprobleem heeft. In dit geval werkt u de pakketversie bij naar een versie waarmee het beveiligingsprobleem wordt opgelost.

Pakketkwetsbaarheden kunnen worden gerapporteerd in zowel directe als transitieve pakketverwijzingen. De actie die u uitvoert om op te lossen, is mogelijk anders.

Beveiligingsproblemen gevonden met updates

Als er beveiligingsproblemen worden gevonden en er updates beschikbaar zijn voor het pakket, kunt u een van de volgende handelingen uitvoeren:

• Pas de locatie van de .csproj of een andere pakketversie (Directory.Packages.props) aan met een nieuwere versie die een beveiligingsfix bevat.
• Gebruik de gebruikersinterface van NuGet Package Manager in Visual Studio om het afzonderlijke pakket bij te werken.
• Voer de dotnet package update --vulnerable opdracht uit om alle kwetsbare pakketten in een project bij te werken naar de eerste versie zonder bekende beveiligingsproblemen.
• Voer de dotnet package update of dotnet package add opdrachten uit met de betreffende pakket-id om bij te werken naar de nieuwste versie. Gebruik dotnet add package deze functie wanneer u .NET 9 of eerder gebruikt.
• Gebruik de MCP-server (NuGet Model Context Protocol) die pakketten in uw project kan bijwerken naar versies die bekende beveiligingsproblemen oplossen. Zie Beveiligingsproblemen in pakketten oplossen voor meer informatie.

Transitieve pakketten

Vaak bevindt een kwetsbaarheid zich in een transitieve afhankelijkheid. Onze aanbeveling is om de voorkeur te geven aan updates voor pakketten die 'het dichtst bij uw directe verwijzingen' liggen. Er is echter niets mis met het upgraden van het pakket met een bekend beveiligingsprobleem.

Stel dat uw project verwijst naar pakket A. Pakket A heeft een afhankelijkheid van pakket B, die op zijn beurt afhankelijk is van pakket C. In dit voorbeeld wordt ervan uitgegaan dat pakket C versie 1.0.0 een bekend beveiligingsprobleem heeft, opgelost in versie 2.0.0. Onze aanbeveling is om eerst een upgrade van pakket A uit te voeren. Als hiermee de controlewaarschuwing niet wordt opgelost, voert u een upgrade uit van pakket B. Als hiermee de controlewaarschuwing niet wordt opgelost, voert u C rechtstreeks bij. Om hierbij te helpen, moet u het transitieve pakketpad vinden.

Kortom, als er een bekend beveiligingsprobleem bestaat in de transitieve afhankelijkheden van een pakket op het hoogste niveau, hebt u de volgende opties:

• Controleer of het pakket op het hoogste niveau een update bevat die geen transitief beveiligingsprobleem heeft en dat in plaats daarvan bijwerkt.
• Werk het dichtstbijzijnde pakket bij dat overeenkomt met uw directe verwijzingen en geen beveiligingsproblemen bevat.
• Voeg de versie van het vaste pakket toe als directe pakketreferentie. Opmerking: Zorg ervoor dat u deze verwijzing verwijdert wanneer er een nieuwe pakketversieupdate beschikbaar is en zorg ervoor dat u de gedefinieerde kenmerken voor het verwachte gedrag onderhoudt.
• Gebruik Central Package Management met de transitieve pinning-functionaliteit. Houd er rekening mee dat als u uw project in uw eigen pakket inpakt om met anderen te delen, CPM met transitieve pincode ervoor zorgt dat pakketten afhankelijkheden worden, zelfs als uw project api's niet rechtstreeks aanroept voor dat pakket.
• Het advies onderdrukken totdat het kan worden aangepakt.
• Dien een melding in de tracker van het hoofdpakket in om een update aan te vragen.

Het transitieve pakketpad zoeken

Er zijn verschillende manieren om het pakketpad te vinden. Welke methode u liever gebruikt, hangt af van welke hulpprogramma's u normaal gesproken gebruikt tijdens uw ontwikkeling.

dotnet nuget why (verklaart het gebruik of afhankelijkheden van een pakket)

Op de opdrachtregel kunt u de dotnet nuget why opdracht gebruiken om te begrijpen waarom transitieve pakketten worden opgenomen in de pakketgrafiek van uw project.

Visual Studio Solution Explorer

SDK-stijlprojecten bieden ook de volledige pakketgrafiek onder het knooppunt Afhankelijkheid van het project. Het is ook doorzoekbaar! Vouw zoekopties uit en schakel externe bestanden zoeken in.

Zoek de pakketnaam op en u ziet alle instanties onder het knooppunt Afhankelijkheden van elk project.

Visual Studio NuGet Package Manager-gebruikersinterface

Wanneer u naar het tabblad Geïnstalleerd in de gebruikersinterface van Pakketbeheer van Visual Studio kijkt en het project PackageReference gebruikt voor pakketbeheer, worden zowel directe als transitieve pakketten weergegeven. Dit gebeurt momenteel alleen wanneer u pakketten voor een project beheert, niet voor de oplossing.

Als u de muisaanwijzer boven een pakket in de pakketlijst houdt, bevat de knopinfo de naam van één direct pakket dat ervoor heeft gezorgd dat het transitieve pakket in het project is opgenomen.

Beveiligingsproblemen gevonden zonder updates

In het geval dat er een bekend beveiligingsprobleem in een pakket bestaat zonder een beveiligingsoplossing, kunt u het volgende doen.

• Controleer op eventuele beperkende factoren die in het adviesrapport worden beschreven.
• Gebruik een voorgesteld pakket als het pakket is gemarkeerd als afgeschaft of wordt afgebroken.
• Als het pakket open source is, kunt u een oplossing bijdragen.
• Open een probleem in de probleemtracker van het pakket.

Controleren op beperkende factoren

Raadpleeg de beveiligingsadviseur voor eventuele beperkende factoren waarmee u het pakket kunt blijven gebruiken met het beveiligingsprobleem. Het beveiligingsprobleem bestaat mogelijk alleen wanneer de code wordt gebruikt voor een specifiek framework, besturingssysteem of een speciale functie.

Een voorgesteld pakket gebruiken

In het geval dat een beveiligingsadvies wordt gerapporteerd voor het pakket dat u gebruikt en het pakket is gemarkeerd als afgeschaft of lijkt afgebroken, kunt u overwegen een voorgesteld alternatief pakket te gebruiken dat de auteur van het pakket heeft gedeclareerd of een pakket dat bestaat uit vergelijkbare functionaliteit die wordt onderhouden.

Een oplossing bijdragen

Als er geen oplossing bestaat voor het beveiligingsadvies, kunt u wijzigingen voorstellen die betrekking hebben op het beveiligingsprobleem in een pull-aanvraag in de opensource-opslagplaats van het pakket of contact opnemen met de auteur via de sectie Contact owners op de pagina met pakketdetails van het NuGet.org pakket.

Een probleem openen

Als u het beveiligingsprobleem niet wilt oplossen of het pakket niet kunt bijwerken of vervangen, opent u een probleem in de probleemtracker of voorkeurscontactmethode van het pakket. Op NuGet.org kunt u naar de pagina met pakketgegevens navigeren en op Report package klikken om contact met de auteur op te halen.

Er zijn geen beveiligingsproblemen gevonden

Als er geen beveiligingsproblemen worden gevonden, betekent dit dat pakketten met bekende beveiligingsproblemen niet zijn gevonden in uw pakketgrafiek op het moment dat u hebt gecontroleerd. Omdat de adviesdatabase op elk gewenst moment kan worden bijgewerkt, raden we u aan uw dotnet restore uitvoer regelmatig te controleren en hetzelfde te garanderen in uw continue integratieproces.

NuGet-controle uitvoeren in CI

Fouten en waarschuwingen gescheiden houden met een toegewezen auditpijplijn

U kunt de voorwaardelijke instructies van MSBuild gebruiken om een toegewezen CI-pijplijn te configureren voor het uitvoeren van controles, zonder dat waarschuwingen worden behandeld als fouten in andere pijplijnen of in lokale builds. Afhankelijk van uw CI-systeem en teamprocessen kunt u mislukte uitvoeringen van de auditpijplijn naar het team laten e-mailen, of u beschikt mogelijk over een dashboard waar u een badge van de meest recente uitvoering van de pijplijn kunt weergeven.

Net als bij het programmeren zijn er meerdere manieren om het resultaat te bereiken. Een optie is om NuGet-auditwaarschuwingen alleen als fouten in een controlepijplijn te behandelen.

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

Vervolgens voert u herstel uit in uw pijplijn, waarbij u de eigenschap specificeert die door de voorwaarde wordt bepaald. Gebruik bijvoorbeeld de syntaxis van GitHub Actions:

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

De naam AuditPipeline van de eigenschap is slechts een voorbeeld en u kunt deze naar wens aanpassen, zolang de naam hetzelfde is in zowel de MSBuild-voorwaarde als de opdrachtregel. MSBuild maakt ook gebruik van omgevingsvariabelen bij het lezen van een eigenschap die nog niet is gedefinieerd, dus een omgevingsvariabele is een alternatief voor de opdrachtregelparameter.

Door voorwaarden te gebruiken om NuGet Audit-waarschuwingen selectief een herstel te laten mislukken, kunt u een speciale pijplijn hebben om pakketten te controleren op bekende beveiligingsproblemen. Tegelijkertijd voorkomt u dat nieuwe beveiligingsadviezen uw bugfixes op ongelegen momenten blokkeren. Door NuGet-auditwaarschuwingen ingeschakeld te houden voor lokale builds, kunnen ontwikkelaars een niet-blokkerende melding krijgen over nieuwe beveiligingsadviezen en kunnen upgraden van pakketversies worden aangemoedigd om de beveiligingsproblemen sneller op te lossen dan te wachten totdat iemand de status van de controlepijplijn controleert.

Gecontroleerde herstelprojecten garanderen

NuGet in MSBuild 17.13 en .NET 9.0.200 toegevoegd uitvoereigenschappen RestoreProjectCount, RestoreSkippedCount en RestoreProjectsAuditedCount voor de hersteltaak. Dit kan worden gebruikt om die controle af te dwingen die is uitgevoerd tijdens een herstelbewerking. Houd er rekening mee dat deze uitvoereigenschappen niet beschikbaar zijn bij het herstellen van statische grafieken.

Aangezien MSBuild een scripttaal is, kan dit op verschillende manieren worden bereikt, maar heeft ook dezelfde beperkingen als MSBuild. Een voorbeeld is het maken van een bestand Directory.Solution.targets in dezelfde map als uw oplossingsbestand, waarvan de inhoud een doel heeft dat vergelijkbaar is met de volgende. Houd er rekening mee dat Directory.Build.props vaak wordt gebruikt, maar wordt geïmporteerd door projecten. Het hersteldoel en de taak van NuGet worden echter uitgevoerd op oplossingsniveau, dus moet zich in het uitbreidbaarheidsbestand van MSBuild bevinden, niet het project-/buildbestand.

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

Afhankelijk van uw gebruikssituatie wilt u mogelijk een voorwaarde '$(RestoreProjectCount)' != '$([MSBuild::Add($(RestoreProjectsAuditedCount), $(RestoreSkippedCount))' toepassen op het foutbericht om rekening te houden met projecten waarvan het herstel werd overgeslagen omdat ze al up-to-date waren. Overweeg ook of u wilt dat deze fout overal optreedt, of alleen in CI-pijplijnen, en welke omgevingsvariabelen zijn gedefinieerd in uw CI-omgeving, en neem dit mee in de voorwaarden voor de doelstelling. Nogmaals, aangezien MSBuild een scripttaal is, kunt u elk van de mogelijkheden ervan gebruiken om uw opslagplaats naar wens aan te passen. Het weergeven van MSBuild's metaproj en binlogs is handig voor het ontwikkelen en oplossen van problemen met doelen op oplossingsniveau.

dotnet list package --vulnerable

dotnet list package heeft een --vulnerable argument om de pakketten te filteren op basis van welke pakketten bekende beveiligingsproblemen hebben. Houd er rekening mee dat --include-transitive niet standaard is, dus moet worden opgenomen.