A private NuGet feed and NuGet proxy

Put a nuget.config next to the solution, with <clear /> so nuget.org is not asked directly, and the token read from the environment:

<configuration>
  <packageSources>
    <clear />
    <add key="company" value="https://packages.example.com/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <company>
      <add key="Username" value="your-user-name" />
      <add key="ClearTextPassword" value="%REPO_TOKEN%" />
    </company>
  </packageSourceCredentials>
</configuration>

The upstream is https://api.nuget.org/v3/index.json, or the index.json of a private feed such as Azure Artifacts with a user name and token. A package is summed up once from the feed's registration pages: its own spelling of the id, every version, when each was published, its license and its dependencies. The version list dotnet restore reads and the registration dotnet add package reads both come from that summary through one filter (kill switch, quarantine, rules, safe version resolution and cooling off), so the two never disagree. Every .nupkg is checked again when it is asked for, hashed, refused unless it is a zip, and then scanned like any other file.

Rules match ids without case, so Newtonsoft.Json and newtonsoft.json are one rule. A bare version is exactly that version. NuGet ranges like [13.0,14.0), floating versions like 13.* and comparators like >=13.0 <14 work too. When something is refused, dotnet prints the reason from the X-NuGet-Warning header, and the refusal opens a request for an approver.

Pushing your own packages

Reserve an id or a prefix like Acme.* under Reserved names, then push with a token whose owner is a publisher, approver or admin:

dotnet nuget push "nupkgs/*.nupkg" --source https://packages.example.com/nuget/v3/index.json --api-key "$REPO_TOKEN"

Only reserved ids can be pushed, and a reserved id is never fetched from nuget.org, so nobody can publish the same id in public and have it restored instead. The id, version, license and dependencies are read from the .nuspec inside the package. A pushed version never changes: pushing it again is refused, and dotnet nuget delete is refused too. A new push is held until its malware scan is clean, or until an admin releases it.

What applies, and what does not

Allow and block rules, the kill switch, quarantine, cooling off, malware scanning (the OSV known malicious check included), license policy, requests and auto approve all work for NuGet. Advisories come from OSV's NuGet feed, for safe version resolution and the scheduled scan. Licenses are read from licenseExpression only, so an older package that points at a license url counts as unknown.

Honest limits: there is no search, so the Browse tab in Visual Studio finds nothing and packages are added by name. Typosquat checks, provenance checks and the dependency tree walk are for npm and PyPI, not NuGet. Repository signatures and the catalog are not served.