To vet a NuGet package, confirm who publishes it, check its ID prefix and signature, see what it pulls in, audit it for known vulnerabilities, and pin which source it may come from. NuGet has built-in controls for each step. None of them proves a package is harmless, so treat them as filters.
Who published it?
Start with the identity signals. Package owners on nuget.org can reserve ID prefixes. When a prefix is reserved, nuget.org rejects any new package using it unless it comes from the owners who reserved it, and packages under the prefix show a visual indicator on nuget.org and in Visual Studio. Microsoft's documentation notes that the Visual Studio indicator appears only when a single feed is selected.
Read the indicator carefully. Older packages that already matched the prefix before reservation remain unchanged and carry no indicator. A missing indicator is a prompt to look closer, not proof of a fake.
Typosquats usually fail this test: a package named like a popular library, from an unknown owner, with no reserved prefix, a handful of downloads and a young history.
Is it signed, and who do you trust?
Signed packages need no action to install, but if content changed after signing, installation is blocked with error NU3008. A package signed with an untrusted certificate is treated as unsigned and installs without warning.
That second point matters. To make signing a control, set signatureValidationMode to require in nuget.config. Then NuGet verifies that every package is signed by a certificate you trust. You declare trust with the trusted-signers settings, by author certificate fingerprint, by repository, or by repository plus a list of owners.
What will it pull in?
Install is the moment to look at the graph. In a project file, dependencies appear as PackageReference items. The dotnet list package command shows direct and transitive dependencies, and dotnet nuget why explains why a transitive package is included. A small utility that drags in forty packages deserves a second look.
Are there known vulnerabilities?
NuGetAudit warns during restore about packages with known vulnerabilities. It arrived with the .NET 8 SDK for direct packages. Microsoft's pages say that for projects targeting .NET 10 or higher the default mode becomes all, covering transitive packages, while older targets default to direct. You can raise coverage by setting NuGetAuditMode to all and choosing a minimum severity with NuGetAuditLevel.
If you do not use nuget.org as a source, add it as an audit source, since NuGetAudit needs a vulnerability database. Remember that a warning means the flaw is already public.
Known vulnerability data says nothing about a brand new malicious package. Those have no advisory yet, which is why identity and behavior checks come first.
Which source may it come from?
If you mix public and private feeds, NuGet by default searches all configured sources, and for a package on several sources the winner may not be deterministic. Package Source Mapping, added in NuGet 6.0, lets you decide per package ID which sources are searched. Map your internal prefixes to your private feed only, which blocks dependency confusion through nuget.org. Microsoft notes the mapping applies to restore, install and update, not yet to every metadata lookup command.
What to do
- Check the package page for owner, ID prefix indicator, download history, repository link and last update.
- Compare the name against the library you meant to install.
- Require signature validation in nuget.config and define trusted signers.
- Run restore with NuGetAudit on, severity at moderate or above, and mode set to all.
- List the transitive packages and read any you do not recognize.
- Add Package Source Mapping entries before adding a private feed.
- Commit the change through code review with a lock file so the exact versions are recorded.
- Scan the resulting build in CI. Safeguard's CLI and Gold free scan can check dependencies for known vulnerabilities and flag unexpected additions.
Quick check
Does a signed NuGet package mean it is safe?
No. A signature shows who signed it and that it was not modified afterwards. Unsigned or untrusted-signature packages install silently unless you require validation.
What does Package Source Mapping prevent?
It stops NuGet from fetching a package ID from a source you did not assign, which helps against dependency confusion when public and private feeds are mixed.
Sources
- Best practices for a secure software supply chain, Microsoft Learn
- Auditing package dependencies for security vulnerabilities, Microsoft Learn
- Manage package trust boundaries, Microsoft Learn
- Package ID prefix reservation, Microsoft Learn
- Package Source Mapping, Microsoft Learn
Last reviewed: 18 October 2026.
