The code you write yourself is only a small part of what runs in the Kladde. On top of it come dozens of NuGet packages, their own dependencies, a base image with an operating system and the tools that build all of it. Each of these can be the path by which foreign code gets into your app: a package with a known vulnerability, a package of the same name from the wrong source, a version changed silently, an image that someone swapped between build and delivery. This lesson closes these paths one after the other. At the end it is settled where each package may come from, which version it has, what is inside the Kladde, and that an image really comes from your build.
New in this lesson:
| Tool | Version | What for |
|---|---|---|
Microsoft.Sbom.DotNetTool (command sbom-tool) |
4.1.13 | generating an SBOM in SPDX format; from Microsoft, open source on GitHub (check the license before the course starts) |
Notation with the plug-in notation-azure-kv |
as in the Microsoft Learn tutorial | signing and verifying container images with a key from Key Vault; open source of the Notary Project, supported by Microsoft (check the license before the course starts) |
Five paths, five countermeasures
| Path into your app | Example | Countermeasure |
|---|---|---|
| a known vulnerability in a package | a package deep down in the tree has a published vulnerability | NuGet Audit as an error, for transitive packages too |
| a package from the wrong source | someone puts a package with the name of your own on nuget.org (dependency confusion) | package source mapping |
| a version that changes unnoticed | a range like [1.0, ) or a newly published transitive package changes the build overnight |
lock files, in the run only in locked mode |
| a tampered package | a package is manipulated on the way or in the cache | signed packages, verified at restore |
| a swapped image | the registry holds a different image under the familiar name | signed images, verified before rolling out, images only from your own registry and by digest |
On top of that comes a bill of materials, the SBOM (software bill of materials). It prevents no attack, but on the day a new vulnerability becomes known, it answers in minutes the question of whether and where the Kladde is affected.