Der Code, den Sie selbst schreiben, ist nur ein kleiner Teil dessen, was in der Kladde läuft. Dazu kommen Dutzende NuGet-Pakete, deren eigene Abhängigkeiten, ein Basis-Image mit einem Betriebssystem und die Werkzeuge, die all das bauen. Jedes davon kann der Weg sein, auf dem fremder Code in Ihre App gelangt: ein Paket mit einer bekannten Lücke, ein gleichnamiges Paket aus einer falschen Quelle, eine stillschweigend geänderte Version, ein Image, das jemand zwischen Build und Auslieferung ausgetauscht hat. Diese Lektion schließt diese Wege einen nach dem anderen. Am Ende steht fest, woher jedes Paket kommen darf, welche Version es hat, was in der Kladde steckt, und dass ein Image wirklich aus Ihrem Build stammt.

Neu in dieser Lektion:

Werkzeug Version wofür
Microsoft.Sbom.DotNetTool (Befehl sbom-tool) 4.1.13 eine SBOM im SPDX-Format erzeugen; von Microsoft, Open Source auf GitHub (Lizenz vor Kursbeginn prüfen)
Notation mit dem Plug-in notation-azure-kv wie im Tutorial von Microsoft Learn Container-Images mit einem Schlüssel aus Key Vault signieren und prüfen; Open Source des Notary Project, von Microsoft unterstützt (Lizenz vor Kursbeginn prüfen)

Fünf Wege, fünf Gegenmittel

Weg in Ihre App Beispiel Gegenmittel
eine bekannte Lücke in einem Paket ein Paket tief unten im Baum hat eine veröffentlichte Lücke NuGet Audit als Fehler, auch für mittelbare Pakete
ein Paket aus der falschen Quelle jemand legt ein Paket mit dem Namen Ihres eigenen auf nuget.org ab (Dependency Confusion) Package Source Mapping
eine Version, die sich unbemerkt ändert ein Bereich wie [1.0, ) oder ein neu veröffentlichtes mittelbares Paket ändert den Build von heute auf morgen Sperrdateien, im Lauf nur im gesperrten Modus
ein verändertes Paket ein Paket wird auf dem Weg oder im Cache manipuliert signierte Pakete, Prüfung beim Restore
ein ausgetauschtes Image in der Registry liegt unter dem bekannten Namen ein anderes Image signierte Images, Prüfung vor dem Ausrollen, Images nur aus der eigenen Registry und per Digest

Dazu kommt eine Stückliste, die SBOM (Software Bill of Materials). Sie verhindert keinen Angriff, aber sie beantwortet am Tag, an dem eine neue Lücke bekannt wird, in Minuten die Frage, ob und wo die Kladde betroffen ist.