What is a NuGet audit source and do I need one?

An audit source is the NuGet feed that supplies vulnerability data to NuGet Audit. If you restore from a private feed and nuget.org is not one of your package sources, you should add nuget.org as an audit source. Otherwise restore may have no vulnerability list to compare against.

The problem it solves

Many teams reduce supply chain risk by restoring from a single private feed that mirrors nuget.org, so developer machines never talk to the public feed directly. That is a sound pattern. It has a side effect: a private feed may not publish vulnerability information, so NuGet Audit has nothing to check against.

Audit sources separate the two jobs. Your package source decides where packages come from. Your audit source decides where advisory data comes from.

How it behaves

• Restore reads a source's vulnerability resource and compares it with the packages each project uses.
• The sources come from the auditSources element in nuget.config.
• If auditSources is not defined, or is cleared without adding any, NuGet falls back to your package sources and warning NU1905 is suppressed.
• If an audit source does not provide vulnerability data, restore raises NU1905.
• Audit sources arrived with NuGet 6.12 and the .NET 9 SDK for restore, and the dotnet list package vulnerable option honors them from .NET SDK 9.0.300.

Two nuget.org endpoints

Microsoft documents two service indexes on nuget.org that can act as an audit source.

The second is useful when your network team blocks api.nuget.org. Because it cannot serve packages, it is easier to justify allowing.

A working configuration

<configuration>
  <packageSources>
    <clear />
    <add key="internal" value="https://nuget.example.internal/v3/index.json" />
  </packageSources>
  <auditSources>
    <clear />
    <add key="nuget.org" value="https://data.nuget.org/v3/index.json" />
  </auditSources>
</configuration>

The data source behind nuget.org's list is the GitHub Advisory Database, filtered to reviewed NuGet advisories.

Steps to check your setup

1. Run a restore with normal verbosity and look for NU1900 or NU1905.
2. Confirm which nuget.config files apply, since settings accumulate from several folders.
3. Add or clear auditSources in the repository nuget.config.
4. Make sure the build agent can reach the audit endpoint.
5. Plant a known vulnerable package in a throwaway project to prove warnings appear.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how new advisories reach an already scanned project, which is the same reason audit data must stay reachable.

Safeguard's dependency scanning checks NuGet projects without needing your feed layout, and a free scan is a quick cross-check.

Quick check

Sources

• Auditing package dependencies for security vulnerabilities, Microsoft Learn
• Best practices for a secure software supply chain, Microsoft Learn
• dotnet package list command, Microsoft Learn

Last reviewed: 19 October 2026.