Freigeben über

Überwachen von Paketabhängigkeiten für Sicherheitsrisiken

  • Artikel

Informationen zu Sicherheitsprüfungen

Eine Sicherheitsüberwachung für Paketmanager wie NuGet ist ein Prozess, der die Analyse der Sicherheit der Pakete umfasst, die in einem Softwareprojekt enthalten sind. Dazu gehören das Identifizieren von Sicherheitsrisiken, die Bewertung von Risiken und das Erstellen von Empfehlungen zur Verbesserung der Sicherheit. Die Prüfung kann eine Überprüfung der Pakete selbst sowie alle Abhängigkeiten und deren damit verbundenen Risiken umfassen. Ziel der Überwachung ist es, Sicherheitsrisiken zu identifizieren und zu mindern, die von Angreifern ausgenutzt werden können, z. B. Codeeinfügung oder websiteübergreifende Skriptingangriffe.

Darüber hinaus wird in unserem Blogbeitrag die empfohlene Vorgehensweise für den Fall erläutert, dass bei Ihrem Projekt ein Paket mit einer bekannten Schwachstelle genutzt wird. Zudem werden darin Tools vorgestellt, mit denen Sie weitere Informationen erhalten können.

Featureverfügbarkeit

NuGet .NET SDK Visual Studio Funktion
5.9 SDK für .NET 5 (5.0.200) N/V dotnet list package --vulnerable
6.8 .NET 8 SDK (8.0.100) Visual Studio 2022 17.8 NuGetAudit für PackageReference
6.10 N/V Visual Studio 2022 17.10 NuGetAudit für packages.config
6.11 SDK für .NET 8 (8.0.400) Visual Studio 2022 17.11 NuGetAuditSuppress for PackageReference
6.12 SDK für .NET 9 (9.0.100) Visual Studio 2022 17.12 Überwachungsquellen. NuGetAuditSuppress für packages.config.

Ausführen einer Sicherheitsüberwachung mit restore

Der Befehl restore wird automatisch ausgeführt, wenn Sie einen allgemeinen Paketvorgang ausführen, z. B. das erstmalige Laden eines Projekts, das Hinzufügen eines neuen Pakets, das Aktualisieren einer Paketversion oder das Entfernen eines Pakets aus Ihrem Projekt in Ihrer bevorzugten IDE. Die Abhängigkeiten werden anhand einer Liste bekannter Schwachstellen überprüft, die von den Überwachungsquellen bereitgestellt wird.

  1. Navigieren Sie in der Befehlszeile zu Ihrem Projekt- oder Lösungsverzeichnis.
  2. Führen Sie restore mit Ihrem bevorzugten Tool aus (z. B. dotnet, MSBuild, NuGet.exe, VisualStudio usw.).
  3. Überprüfen Sie den Warnungen, und beheben Sie die bekannten Sicherheitsrisiken.

Konfigurieren der NuGet-Überwachung

Die Überwachung kann über MSBuild-Eigenschaften in einer .csproj- oder MSBuild-Datei konfiguriert werden, die als Teil Ihres Projekts ausgewertet wird. Es wird empfohlen, dass die Überwachung auf Repository-Ebene konfiguriert ist.

MSBuild-Eigenschaft Standard Mögliche Werte Hinweise
NuGetAuditMode direkt direct und all Wenn Sie nur Abhängigkeiten auf oberster Ebene überwachen möchten, können Sie den Wert auf direct. NuGetAuditMode gilt nicht für Packages.config-Projekte.
NuGetAuditLevel low low, moderate, high und critical Der zu meldende minimale Schweregrad. Wenn Sie Hinweise für moderate, high und critical anzeigen möchten (low ausgenommen), setzen Sie den Wert auf moderate.
NuGetAudit true true und false Wenn Sie keine Berichte über Sicherheitsüberwachungen erhalten möchten, können Sie diese Erfahrung ganz ausschalten, indem Sie den Wert auf false setzen.

Überwachungsquellen

Durch das Wiederherstellen wird die Ressource VulnerabilityInfo eines Servers heruntergeladen, um eine Überprüfung anhand der Liste der Pakete vorzunehmen, die die einzelnen Projekte nutzen. Die Liste der Quellen wird durch das Element auditSources in NuGet.Config definiert. Zudem wird die Warnung NU1905 ausgelöst, wenn einer der Überwachungsquellen keine Informationen zu Schwachstellen bereitstellt. Wenn auditSources nicht definiert ist oder gelöscht wird, ohne Quellen hinzuzufügen, wird packageSources verwendet und die Warnung NU1905 unterdrückt.

Da eine gängige Gegenmaßnahme für Paketersetzungsangriffe darin besteht , eine einzelne Paketquelle zu verwenden, die von nuget.org geladen wird, sodass NuGet nicht zur Nutzung von nuget.org als Paketquelle konfiguriert ist, können Überwachungsquellen eingesetzt werden, um nuget.org (oder eine andere Quelle, die Informationen zu Schwachstellen bereitstellt) zu nutzen, ohne sie auch als Paketquelle zu verwenden.

Die Datenquelle für die Schwachstellendatenbank von nuget.org ist GitHub Advisory Database. Beachten Sie, dass das V2-Protokoll veraltet ist. Wenn nuget.config weiterhin den V2-Endpunkt nutzt, müssen Sie daher zum V3-Endpunkt migrieren.

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

Überwachungsquellen sind ab NuGet 6.12, dem SDK für .NET 9.0.100 und Visual Studio 2022 17.12 verfügbar. Vor dieser Version nutzt NuGet Audit nur Paketquellen zum Herunterladen von Informationen zu Schwachstellen. Überwachungsquellen werden von dotnet list package --vulnerable derzeit nicht verwendet.

Ausschließen von Empfehlungen

Sie können bestimmte Empfehlungen aus dem Überwachungsbericht ausschließen, indem Sie für jede Empfehlung ein neues NuGetAuditSuppress-MSBuild-Element hinzufügen. Definieren Sie ein NuGetAuditSuppress-Element mit den Include=-Metadaten, die für die Empfehlungs-URL festgelegt sind, die Sie unterdrücken möchten.

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

Ähnlich wie die anderen Eigenschaften der NuGet-Überwachungskonfiguration, können NuGetAuditSuppress-Elemente auf Projekt- oder Repositoryebene definiert werden.

NuGetAuditSuppress ist für PackageReference-Projekte ab NuGet 6.11, Visual Studio 17.11 und .NET 8.0.400 SDK verfügbar. Es ist für packages.config mit Visual Studio 17.12 und NuGet 6.12 verfügbar.

Warncodes

Warncode Grund
NU1900 Fehler bei der Kommunikation mit der Paketquelle beim Abrufen von Sicherheitsrisikeninformationen.
NU1901 Paket mit geringem Schweregrad erkannt
NU1902 Paket mit mittlerem Schweregrad erkannt
NU1903 Paket mit hohem Schweregrad erkannt
NU1904 Paket mit kritischem Schweregrad erkannt
NU1905 Eine Überwachungsquelle stellt keine Schwachstellendatenbank bereit.

Sie können Ihren Build so anpassen, dass diese Warnungen als Fehler behandelt werden, um Warnungen als Fehler zu behandeln oder Warnungen nicht als Fehler zu behandeln. Wenn Sie z. B. bereits <TreatWarningsAsErrors> verwenden, um alle Warnungen (C#, NuGet, MSBuild usw.) als Fehler zu behandeln, können Sie <WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> verwenden, um zu verhindern, dass Sicherheitsrisiken, die in Zukunft entdeckt werden, Ihren Build unterbrechen. Alternativ können Sie, wenn Sie niedrige und moderate Sicherheitsrisiken als Warnungen beibehalten möchten, aber hohe und kritische Sicherheitsrisiken als Fehler behandeln, und nicht TreatWarningsAsErrors verwenden, können Sie <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors> verwenden.

Hinweis

MSBuild-Eigenschaften für den Nachrichtenschweregrad, z. B. NoWarn und TreatWarningsAsErrors werden für packages.config-Projekte nicht unterstützt.

dotnet list package --vulnerable

Nach der erfolgreichen Widerherstellung eines Projekts weist dotnet list package ein --vulnerable-Argument zum Filtern der Pakete basierend auf bekannten Schwachstellen auf. Beachten Sie, dass --include-transitive dies nicht der Standard ist, daher sollte sie eingeschlossen werden.

Aktionen bei der Meldung von Paketen mit bekannten Schwachstellen

Darüber hinaus wird in unserem Blogbeitrag die empfohlene Vorgehensweise für den Fall erläutert, dass bei Ihrem Projekt ein Paket mit einer bekannten Schwachstelle genutzt wird. Zudem werden darin Tools vorgestellt, mit denen Sie weitere Informationen erhalten können.

Sicherheitsrisiken, die mit Updates gefunden wurden

Wenn Sicherheitsrisiken gefunden werden und Updates für das Paket verfügbar sind, können Sie eine der folgenden Aktionen ausführen:

  • Bearbeiten Sie den Speicherort von .csproj oder einen anderen Paketversionsspeicherort (Directory.Packages.props) mit einer neueren Version, die einen Sicherheitspatch enthält.
  • Verwenden Sie in Visual Studio den NuGet-Paket-Manager zum Installieren des Pakets.
  • Führen Sie den Befehl dotnet add package mit der jeweiligen Paket-ID aus, um auf die neueste Version zu aktualisieren.

Transitive Pakete

Wenn eine bekannte Sicherheitsanfälligkeit in den transitiven Abhängigkeiten eines Pakets auf oberster Ebene vorhanden ist, haben Sie folgende Optionen:

  • Fügen Sie die feste Paketversion als direkten Paketverweis hinzu. Hinweis: Achten Sie darauf, diesen Verweis zu entfernen, wenn ein neues Paketversionsupdate verfügbar ist, und achten Sie darauf, die definierten Attribute für das erwartete Verhalten beizubehalten.
  • Verwenden Sie die zentrale Paketverwaltung mit der transitiven Pinningfunktion.
  • Unterdrücken Sie die Empfehlung , bis sie behoben werden kann.
  • Dateiieren Sie ein Problem im Tracker des Pakets der obersten Ebene, um ein Update anzufordern.

Sicherheitsrisiken ohne Updates gefunden

In dem Fall, dass eine bekannte Sicherheitsanfälligkeit in einem Paket ohne Sicherheitskorrektur vorhanden ist, können Sie die folgenden Schritte ausführen.

  • Überprüfen Sie alle im Beratungsbericht beschriebenen mildernden Faktoren.
  • Verwenden Sie ein vorgeschlagenes Paket, wenn das Paket als veraltet gekennzeichnet oder abgebrochen wurde.
  • Wenn das Paket open Source ist, sollten Sie einen Fix beitragen.
  • Öffnen Sie ein Problem in der Problemverfolgung des Pakets.

Überprüfen auf Milderungsfaktoren

Überprüfen Sie den Sicherheitsratgeber für alle mildernden Faktoren, mit denen Sie das Paket weiterhin mit der Sicherheitsanfälligkeit verwenden können. Die Sicherheitsanfälligkeit kann nur vorhanden sein, wenn der Code in einem bestimmten Framework, Betriebssystem oder einer speziellen Funktion aufgerufen wird.

Verwenden eines vorgeschlagenen Pakets

Wenn für das verwendete Paket eine Sicherheitsempfehlung gemeldet wird und das Paket als veraltet gekennzeichnet oder nicht mehr unterstützt wird, erwägen Sie die Verwendung eines vorgeschlagenen alternativen Pakets, das der Paketautor deklariert hat, oder ein Paket, das aus ähnlichen Funktionen besteht, die Standard tained sind.

Beitragen eines Fixes

Wenn für die Sicherheitsempfehlung kein Fix vorhanden ist, können Sie Änderungen vorschlagen, die die Sicherheitsanfälligkeit in einer Pullanforderung im Open Source-Repository des Pakets beheben oder den Autor über den Abschnitt Contact owners auf der NuGet.org Paketdetailseite kontaktieren.

Öffnen eines Issues

Wenn Sie die Sicherheitsanfälligkeit nicht beheben oder das Paket nicht aktualisieren oder ersetzen können, öffnen Sie ein Problem in der Problemverfolgung oder bevorzugten Kontaktmethode des Pakets. Auf NuGet.org können Sie zur Seite mit den Paketdetails navigieren und Report package klicken, auf die Sie zum Kontakt mit dem Autor führen.

Es wurden keine Sicherheitsrisiken gefunden

Wenn keine Sicherheitsrisiken gefunden werden, bedeutet dies, dass Pakete mit bekannten Sicherheitsrisiken im Paketdiagramm zum aktuellen Zeitpunkt, zu dem Sie überprüft haben, nicht gefunden wurden. Da die Beratungsdatenbank jederzeit aktualisiert werden kann, empfehlen wir, ihre dotnet restore-Ausgabe regelmäßig zu überprüfen und dasselbe in Ihrem kontinuierlichen Integrationsprozess sicherzustellen.

Zusammenfassung

Sicherheitsauditfunktionen sind für die Aufrechterhaltung der Sicherheit und Integrität von Softwareprojekten von entscheidender Bedeutung. Diese Funktionen bieten Ihnen einen zusätzlichen Schutz vor Sicherheitslücken und gewährleisten, dass Sie Open-Source-Pakete vertrauensvoll nutzen können.