You’ve probably arrived on this page after watching my talk “How to attack a .NET software supply chain” at the VisugXL conference (October 2022 in Hasselt, Belgium), also presented under the name “How your .NET software supply chain is open to attack : and how to fix it” at Techorama Belgium (May 2023), Techorama Netherlands (October 2023) and WeAreDevelopers Berlin (July 2024). The source code for my demos is on GitHub, feel free to use it when explaining these problems to your colleagues. In the “slides” folder you can find the Techorama and WeAreDevelopers slides.

As a reminder, these are the easy steps to do in order to secure you NuGet supply chain against typosquatting and dependency confusion supply chain attacks:

  1. Use <clear /> to avoid inheriting the system configuration (because of how settings are applied in NuGet). By using <clear />, you ensure the NuGet resolution of your builds are fully deterministic and repeatable.
  2. Use Package Source Mapping if you have a hybrid (private and public) configuration, to be protected against dependency confusion attacks. You can use the NuGet.PackageSourceMapper tool to help you generate the configuration for your repository. Alternatively, instead of using multiple package sources, configure only a single package source and control which packages you mirror from the public source in your private source.
  3. Use <trusted signers>: see Manage package trust boundaries. You can use trusted signers for both signed packages (when you will provide the certificate hash), and for unsigned packages (by simply providing the name of the account that published the package you trust). This will help defend your project against unwanted typosquatting attacks.
  4. Reserve prefixes for both your public and private packages on nuget.org: Package ID prefix reservation. It is important to reserve the prefixes for your private packages so that malicious users won’t publish public packages with those names, to attempt dependency confusion attacks. Reserving prefixes for public packages also reduces the surface attack of typosquatting attacks.

These are my top recommendations. You can find more on Microsoft’s NuGet Security Best Practices.

In addition, to have the overview of all your direct and transitive dependencies and be aware of changes in your dependency graph use a NuGet lock file.

Moreover, a general good practice is to use fixed (pinned) versions for your dependencies, to limit the surface of a dependency confusion attack.

Last but not least, if you sign the packages you publish (both public and private ones), you enable your consumers to use <trusted signers> in the best way possible, by also verifying the signature of the owner (not only the signature of the repository).

Some real life NuGet configurations:

For more docs from Microsoft and more resources on software supply chain attacks, read the second part of this post.

Last, but not least: we’re hiring at Sonar!

Version Date Change
2022-10-26 Initial version
2024-07-15 Update title, mention other talks, remove 2022 feedback form. Add reference to the NuGet.PackageSourceMapper tool. Mention <clear />. Add more details. Mention using fixed versions. Move link to github at the beginning of the article.