Supply-Chain Security

Source: NuGet: Best practices for a secure software supply chain, Package Source Mapping, Lock files, Client trust policies, Package ID prefix reservation.

Since NuGet 6.12 (Visual Studio 17.12, .NET 9.0.100), an http:// source is an error for restore and push, not the earlier warning NU1803. A project whose nuget.config lists the local BaGetter server over HTTP:

The opt-out is per source, allowInsecureConnections="true" — acceptable for a server on localhost, as in Ledgerline, and not for anything that crosses a network. For one-off commands, dotnet nuget add source and dotnet nuget push accept --allow-insecure-connections. The documentation’s version labels for these are inconsistent: the HTTPS page gives ".NET 9.0.1xx" for add source and ".NET 10.0.1xx" for push, while the NuGet release notes introduced the option in NuGet 6.11 / SDK 8.0.400; and its rollout table pairs .NET 6.0.100 with NuGet 6.3, although SDK 6.0.100 shipped NuGet 6.0.

Source: NuGet HTTPS Everywhere: Understanding the HTTP error, Allowing insecure HTTP feeds.

Restore checks every resolved package against the vulnerability data the sources publish (nuget.org mirrors the GitHub Advisory Database). Since .NET 10, projects targeting net10.0 or later audit all packages, transitive ones included (NuGetAuditMode=all); older TFMs audit direct references only by default. Restoring a project that references NuGet.Protocol 5.11.2 — the example the NuGet documentation uses — reports the package and four of its dependencies:

The documentation shows GHSA-g3q9-xf95-8hp5 as a moderate (NU1902) finding; on 2026-10-23 the advisory was rated high, so the code is NU1903 — the codes follow the advisory’s current severity (NU1901 low, NU1902 moderate, NU1903 high, NU1904 critical). They are warnings: with TreatWarningsAsErrors they fail the build, which is the intent; hiding them with NoWarn defeats it (suppress a specific advisory with NuGetAuditSuppress instead). The audit needs the sources to be reachable — an unreachable source gives NU1900, as the container example on CI Builds and Caching shows.

Source: NuGet: Auditing package dependencies for security vulnerabilities.

Every package on nuget.org carries a repository signature by nuget.org; many also carry an author signature. dotnet nuget verify checks them, and the trustedSigners section of nuget.config, together with signatureValidationMode="require", makes restore refuse packages not signed by a listed author or repository (optionally restricted to a list of nuget.org owners). The commands and the full trust-policy setup are on Signed Packages and Trust Policies.

Source: NuGet: Client trust policies.

A newly published malicious version is typically detected and removed within hours or days. A cooldown keeps restore from selecting versions younger than a threshold. The .NET 11 preview SDK adds --min-publish-age-hours to dotnet nuget add source and dotnet nuget update source, writing a minPublishAgeHours attribute to the source in nuget.config; dotnet package add and dotnet package update respect it, and restore of a floating version fails with NU1020 when no version is old enough. Not available in SDK 10.0.402 and not run here:

minPublishAgeHours and NU1020 have no reference pages yet; the what’s-new page is the only documentation.

Source: What’s new in the .NET 11 SDK: Configure minimum package publication age from the CLI.

Building a project means running its code. The MSBuild security guidance comes down to four rules:

Source: MSBuild: Security best practices, NuGet: Build agents.

These are covered on Trusted Publishing, nuget.org Accounts and API Keys and Managing Published Packages.

Source: NuGet: Deprecating and unlisting a vulnerable package, nuget.org: Trusted Publishing.