SBOM für .NET- und NuGet-Projekte nach dem CRA
Auf dieser Seite
Der Cyber Resilience Act verlangt von jedem Hersteller eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene des Produkts erfasst (Anhang I Teil II Nummer 1). In .NET sind die NuGet-Pakete nur ein Teil der Antwort. Auch die Laufzeitumgebung, auf der Ihre Anwendung läuft, ist eine Komponente, und wenn Sie sie mit dem Produkt ausliefern, werden ihre Supportdaten zu Ihren.
Zur Verordnung selbst siehe SBOM für den Cyber Resilience Act.
Die NuGet-Lock-Datei einschalten
PackageReference-Projekte schreiben keine Lock-Datei, wenn Sie es nicht verlangen. Fügen Sie dies jedem Projekt hinzu, oder Directory.Build.props für die ganze Solution:
<PropertyGroup>
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>
dotnet restore schreibt dann packages.lock.json neben jedes Projekt, mit jedem direkten und transitiven Paket in seiner aufgelösten Version und seinem Inhalts-Hash. Checken Sie sie ein und führen Sie in der CI dotnet restore --locked-mode aus, damit ein Build fehlschlägt, statt stillschweigend andere Versionen aufzulösen. Ältere Projekte, die noch packages.config nutzen, listen ihre Pakete dort.
Die SBOM erzeugen
Das CycloneDX-Modul für .NET liest eine Solution oder ein Projekt und schreibt CycloneDX:
dotnet tool install --global CycloneDX
dotnet-CycloneDX MySolution.sln -o sbom -F Json
Bei einer Solution fasst es alle Projekte zusammen; -rs folgt stattdessen den Projektverweisen eines einzelnen Projekts. Testprojekte gehören zu den Projekten der Solution, also schließen Sie sie aus (--exclude-test-projects) oder richten Sie das Werkzeug auf das Projekt, das Sie tatsächlich ausliefern.
Microsofts eigenes sbom-tool geht anders vor. Es durchsucht die Build-Ausgabe und den Quellordner zusammen und schreibt SPDX:
sbom-tool generate -b ./publish -bc ./src -pn MyProduct -pv 2.4.0 -ps "Acme Ltd" -nsb https://acme.example/sbom -mi SPDX:3.0
Standardmäßig schreibt es SPDX 2.2; -mi SPDX:3.0 wählt SPDX 3.0. Da es vom veröffentlichten Ordner ausgeht, beschreibt es die Dateien, die tatsächlich ausgeliefert werden, mit ihren Hashes.
Die Laufzeit gehört zum Produkt
Wie Sie veröffentlichen, entscheidet, was im Produkt steckt:
- Framework-abhängig: Die Anwendung erwartet eine bereits auf dem Rechner des Kunden installierte .NET-Laufzeit. Ihre SBOM deckt Ihre Pakete ab; Ihre Dokumentation muss angeben, welche Laufzeitversion erforderlich ist und dass sie aktuell gehalten werden muss.
- Eigenständig (
--self-contained) sowie jeder Native-AOT-Build: Die Laufzeit oder die Teile davon, die Sie nutzen, werden in Ihrem Produkt ausgeliefert. Ihre Version ist eine Komponente, und Microsofts monatliche Sicherheitsupdates werden zu Updates Ihres Produkts.
Die Supportdaten folgen derselben Logik. Der Support für .NET 8 und .NET 9 endet am 10. November 2026; .NET 10, eine Version mit Langzeitsupport, wird bis November 2028 unterstützt. Ein eigenständig auf .NET 8 ausgeliefertes Produkt erhält ab diesem Datum keine Sicherheitskorrekturen der Laufzeit mehr, während der CRA erwartet, dass Sie Schwachstellen während des gesamten angekündigten Unterstützungszeitraums behandeln (Artikel 13 Absatz 8). Prüfen Sie das Supportende der Laufzeit gegen Ihr eigenes, bevor Sie es ankündigen.
Von der SBOM zu den Schwachstellen
NuGet prüft Pakete während dotnet restore gegen die GitHub Advisory Database (NuGet Audit, seit dem .NET-8-SDK standardmäßig aktiv), und dotnet list package --vulnerable --include-transitive listet, was es findet. Schauen Sie zuerst auf die in freier Wildbahn ausgenutzten Schwachstellen, die die Meldeuhr starten können, und halten Sie in einer VEX-Aussage fest, warum die übrigen Ihr Produkt nicht betreffen, wenn das der Fall ist.
Wie Provetry hilft
Provetry liest packages.lock.json aus Ihrer CI oder aus den hochgeladenen Dateien, mit den direkten Abhängigkeiten, die die Lock-Datei festhält, schreibt die SBOM jeder Version in CycloneDX, in den kostenpflichtigen Tarifen auch in SPDX, und überwacht jedes Paket auf neue und ausgenutzte Schwachstellen, täglich in den kostenpflichtigen Tarifen und wöchentlich im kostenlosen. Sie können auch die SBOM hochladen, die CycloneDX für .NET oder sbom-tool geschrieben hat. Sein CI-Schritt zeigt, wo Ihr Code ein verwundbares Paket importiert, mit Datei und Zeile. Bei NuGet-Paketen schließt er nie, dass ein Paket ungenutzt ist, weil Namespaces nicht zuverlässig verraten, aus welchem Paket sie stammen. Für die Laufzeit tragen Sie das Ende Ihres Unterstützungszeitraums im Profil des Produkts ein und vergleichen es mit Microsofts Daten.