Inspekcja zależności pakietów pod kątem luk w zabezpieczeniach

Informacje o inspekcjach zabezpieczeń

Inspekcja zabezpieczeń dla menedżerów pakietów, takich jak NuGet, to proces obejmujący analizowanie zabezpieczeń pakietów zawartych w projekcie oprogramowania. Obejmuje to identyfikowanie luk w zabezpieczeniach, ocenianie zagrożeń i zalecenia dotyczące poprawy bezpieczeństwa. Inspekcja może obejmować przegląd samych pakietów, a także wszelkie zależności i powiązane z nimi zagrożenia. Celem inspekcji jest zidentyfikowanie i ograniczenie wszelkich luk w zabezpieczeniach, które mogą zostać wykorzystane przez osoby atakujące, takie jak wstrzyknięcie kodu lub ataki skryptowe obejmujące wiele witryn.

Mamy również wpis w blogu, w którym omówiono naszą zalecaną metodę podejmowania działań w przypadku znalezienia pakietu ze znaną luką w zabezpieczeniach, która ma być używana przez projekt, oraz narzędzia ułatwiające uzyskanie dodatkowych informacji.

Dostępność funkcji

NuGet	Zestaw SDK platformy .NET	Visual Studio	Funkcja
5.9	Zestaw .NET 5 SDK (5.0.200)	Nie dotyczy	dotnet list package --vulnerable
6.8	Zestaw .NET 8 SDK (8.0.100)	Visual Studio 2022 17.8	NuGetAudit dla elementu PackageReference
6.10	Nie dotyczy	Visual Studio 2022 17.10	NuGetAudit for packages.config
6.11	Zestaw .NET 8 SDK (8.0.400)	Visual Studio 2022 17.11	NuGetAuditSuppress dla elementu PackageReference
6.12	Zestaw .NET 9 SDK (9.0.100)	Visual Studio 2022 17.12	Źródła inspekcji. NuGetAuditSuppress dla pliku packages.config.

Uruchamianie inspekcji zabezpieczeń za pomocą polecenia restore

Polecenie restore jest uruchamiane automatycznie, gdy wykonujesz typową operację pakietu, taką jak ładowanie projektu po raz pierwszy, dodawanie nowego pakietu, aktualizowanie wersji pakietu lub usuwanie pakietu z projektu w ulubionym środowisku IDE. Zależności są sprawdzane pod kątem listy znanych luk w zabezpieczeniach udostępnianych przez źródła inspekcji.

1. W wierszu polecenia przejdź do katalogu projektu lub rozwiązania.
2. Uruchom restore polecenie przy użyciu preferowanych narzędzi (np. dotnet, MSBuild, NuGet.exe, VisualStudio itp.).
3. Przejrzyj ostrzeżenia i rozwiąż znane luki w zabezpieczeniach.

Konfigurowanie inspekcji narzędzia NuGet

Inspekcję można skonfigurować za pomocą właściwości programu MSBuild w pliku MSBuild ocenianym jako .csproj część projektu. Zalecamy skonfigurowanie inspekcji na poziomie repozytorium.

Właściwość MSBuild	Wartość domyślna	Możliwe wartości	Uwagi
NuGetAuditMode	wszystkie (1)	direct i all	Jeśli chcesz przeprowadzić inspekcję zarówno zależności najwyższego poziomu, jak i przechodnich, możesz ustawić wartość na all. Moduł NuGetAuditMode nie ma zastosowania do projektów packages.config
NuGetAuditLevel	Niski	low, moderate, highi critical	Minimalny poziom ważności do raportowania. Jeśli chcesz zobaczyć moderate, highi critical porady (wykluczanie low), ustaw wartość na moderate
NuGetAudit	prawda	true i false	Jeśli nie chcesz otrzymywać raportów inspekcji zabezpieczeń, możesz całkowicie zrezygnować ze środowiska, ustawiając wartość na false

(1) Wartość domyślna direct nuGetAuditMode została wprowadzona w zestawie SDK platformy .NET 8.0.100 i vs 17.8. W zestawie .NET 9.0.100 SDK i VS 17.12 wartość domyślna została zmieniona na all.

Źródła inspekcji

Przywracanie pobiera zasób serwera VulnerabilityInfo w celu sprawdzenia listy pakietów, z których korzysta każdy projekt. Lista źródeł jest definiowana przez auditSources element w pliku NuGet.Config, a ostrzeżenie NU1905 jest zgłaszane, jeśli którekolwiek ze źródeł inspekcji nie udostępnia żadnych informacji o lukach w zabezpieczeniach. Jeśli auditSources nie zdefiniowano lub nie zostanie wyczyszczone bez dodawania żadnych źródeł, packageSources zostanie użyte ostrzeżenie NU1905 zostanie pominięte.

Ponieważ typowym ograniczeniem ryzyka ataków polegających na podstawie pakietów jest użycie pojedynczego źródła pakietu nadrzędnego z nuget.org, dzięki czemu pakiet NuGet nie jest skonfigurowany do używania nuget.org jako źródła pakietów, źródła inspekcji mogą służyć do używania nuget.org (lub innych źródeł, które udostępniają informacje o lukach w zabezpieczeniach) bez używania go jako źródła pakietu.

Źródło danych bazy danych luk w zabezpieczeniach nuget.org to baza danych doradczych usługi GitHub. Należy pamiętać, że protokół V2 jest przestarzały, więc jeśli twój plik nuget.config nadal używa punktu końcowego w wersji 2, musisz przeprowadzić migrację do punktu końcowego w wersji 3.

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

Źródła inspekcji są dostępne w pakietach NuGet 6.12, .NET 9.0.100 SDK i Visual Studio 2022 17.12. Przed tą wersją inspekcja NuGet będzie używać tylko źródeł pakietów do pobierania informacji o lukach w zabezpieczeniach. Obecnie źródła inspekcji nie są używane dotnet list package --vulnerable .

Wykluczanie porad

Możesz wykluczyć określone biuletyny z raportu inspekcji, dodając nowy NuGetAuditSuppress element MSBuild dla każdego poradnika. Zdefiniuj NuGetAuditSuppress Include= element z metadanymi ustawionym na adres URL porady, który chcesz pominąć.

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

Podobnie jak w przypadku innych właściwości konfiguracji inspekcji narzędzia NuGet, NuGetAuditSuppress elementy można zdefiniować na poziomie projektu lub repozytorium.

NuGetAuditSuppress Jest dostępny dla projektów PackageReference począwszy od nuGet 6.11, Visual Studio 17.11 i .NET 8.0.400 SDK. Jest dostępny dla pakietów.config z programu Visual Studio 17.12 i NuGet 6.12.

Kody ostrzegawcze

Kod ostrzegawczy	Przyczyna
NU1900	Błąd podczas komunikowania się ze źródłem pakietu podczas uzyskiwania informacji o lukach w zabezpieczeniach.
NU1901	Wykryto pakiet o niskiej ważności
NU1902	Pakiet z wykrytą umiarkowaną ważnością
NU1903	Wykryto pakiet o wysokiej ważności
NU1904	Pakiet z wykrytą ważnością krytyczną
NU1905	Źródło inspekcji nie zapewnia bazy danych luk w zabezpieczeniach

Możesz dostosować kompilację, aby traktować te ostrzeżenia jako błędy, aby traktować ostrzeżenia jako błędy lub traktować ostrzeżenia nie jako błędy. Jeśli na przykład używasz już <TreatWarningsAsErrors> do traktowania wszystkich ostrzeżeń (C#, NuGet, MSBuild itp.) jako błędów, możesz użyć polecenia <WarningsNotAsErrors>NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> , aby zapobiec wykryciu luk w zabezpieczeniach w przyszłości przed przerwaniem kompilacji. Alternatywnie, jeśli chcesz zachować niskie i umiarkowane luki w zabezpieczeniach jako ostrzeżenia, ale traktować wysokie i krytyczne luki w zabezpieczeniach jako błędy, a nie używasz TreatWarningsAsErrorsmetody , możesz użyć polecenia <WarningsAsErrors>NU1903;NU1904</WarningsAsErrors>.

Uwaga

Właściwości programu MSBuild dla ważności komunikatów, takie jak NoWarn i TreatWarningsAsErrors nie są obsługiwane w przypadku projektów packages.config.

dotnet list package --vulnerable

Po pomyślnym przywróceniu dotnet list package projektu argumentem jest --vulnerable filtrowanie pakietów na podstawie znanych luk w zabezpieczeniach. Należy pamiętać, że --include-transitive nie jest to ustawienie domyślne, dlatego należy je uwzględnić

Akcje, gdy są zgłaszane pakiety ze znanymi lukami w zabezpieczeniach

Mamy również wpis w blogu, w którym omówiono naszą zalecaną metodę podejmowania działań w przypadku znalezienia pakietu ze znaną luką w zabezpieczeniach, która ma być używana przez projekt, oraz narzędzia ułatwiające uzyskanie dodatkowych informacji.

Wykryte luki w zabezpieczeniach z aktualizacjami

Jeśli zostaną znalezione luki w zabezpieczeniach i aktualizacje są dostępne dla pakietu, możesz wykonać następujące czynności:

• Edytuj lokalizację .csproj lub inną wersję pakietu (Directory.Packages.props) przy użyciu nowszej wersji zawierającej poprawkę zabezpieczeń.
• Użyj interfejsu użytkownika menedżera pakietów NuGet w programie Visual Studio, aby zaktualizować pojedynczy pakiet.
• dotnet add package Uruchom polecenie z odpowiednim identyfikatorem pakietu, aby zaktualizować go do najnowszej wersji.

Wykryto luki w zabezpieczeniach bez aktualizacji

W przypadku, gdy w pakiecie istnieje znana luka w zabezpieczeniach bez poprawki zabezpieczeń, możesz wykonać następujące czynności.

• Sprawdź, czy nie ma żadnych czynników korygujących opisanych w raporcie doradczym.
• Użyj sugerowanego pakietu, jeśli pakiet jest oznaczony jako przestarzały lub jest porzucony.
• Jeśli pakiet jest open source, rozważ współtworzenia poprawki.
• Otwórz problem w monitorze problemów pakietu.

Sprawdzanie czynników korygujących

Przejrzyj doradcę zabezpieczeń pod kątem wszelkich czynników korygujących, które mogą umożliwić kontynuowanie korzystania z pakietu z luką w zabezpieczeniach. Luka w zabezpieczeniach może istnieć tylko wtedy, gdy kod jest używany w określonej strukturze, systemie operacyjnym lub wywołaniu specjalnej funkcji.

Korzystanie z sugerowanego pakietu

W przypadku zgłaszania porady dotyczącej zabezpieczeń dla używanego pakietu, a pakiet jest oznaczony jako przestarzały lub wydaje się porzucony, rozważ użycie dowolnego sugerowanego pakietu alternatywnego zadeklarowanego przez autora pakietu lub pakietu składającego się z podobnych funkcji, które są obsługiwane.

Współtworzenie poprawki

Jeśli poprawka nie istnieje w biuletynie zabezpieczeń, możesz zasugerować zmiany, które dotyczą luki w zabezpieczeniach w żądaniu ściągnięcia w repozytorium open source pakietu lub skontaktować się z autorem za pośrednictwem Contact owners sekcji na stronie szczegółów pakietu NuGet.org.

Otwórz problem

Jeśli nie chcesz naprawić luki w zabezpieczeniach lub nie możesz zaktualizować lub zastąpić pakietu, otwórz problem w monitorze problemów pakietu lub preferowanej metodzie kontaktu. Na NuGet.org możesz przejść do strony szczegółów pakietu i kliknąć Report package , aby uzyskać kontakt z autorem.

Nie znaleziono luk w zabezpieczeniach

Jeśli nie znaleziono żadnych luk w zabezpieczeniach, oznacza to, że pakiety ze znanymi lukami w zabezpieczeniach nie zostały znalezione w grafie pakietu w chwili obecnej sprawdzenia. Ponieważ baza danych doradczych może być aktualizowana w dowolnym momencie, zalecamy regularne sprawdzanie dotnet restore danych wyjściowych i zapewnienie tego samego w procesie ciągłej integracji.

Podsumowanie

Funkcje inspekcji zabezpieczeń mają kluczowe znaczenie dla utrzymania bezpieczeństwa i integralności projektów oprogramowania. Te funkcje zapewniają dodatkową warstwę ochrony przed lukami w zabezpieczeniach i zapewniają, że można z pewnością używać pakietów typu open source.