Visual Studio now includes a Package Manager that downloads and updates software packages from the internet. The common name for this is "Nuget"

The problem I have is that anyone can pretend to be someone else, by spoofing the owner field. This opens up a whole can of worms with regard to updates, and verifying the authenticity of every patch.

  • Are these valid concerns? (did I miss any?)

  • What technical and procedural controls can we implement to limit risk?

  • Is there any way to use Nuget in a secure manner?

  • I am surprised none of the answers touched on the idea of a nuget package author adding malicious code. Nuget gallery does not expose the origin or proof of the source code, does not build it and does not audit it, unless I see a rebuttal... Even Maven Central does not have resources to check the incoming code. stackoverflow.com/questions/24967270/…
    – eel ghEEz
    Nov 26, 2019 at 17:19

3 Answers 3


NuGet does not currently support code signing for package or nuspec files, so the author of the package cannot truly be identified. This issue was raised as a feature request in 2010, but it didn’t get much attention and hasn’t been implemented. See http://nuget.codeplex.com/workitem/79.

Currently an already existing package NuGet can only be upgraded by the same account that it was originally uploaded by but this does not verify the actual author of the code which I believe is what you are getting at.

Outside of NuGet, code signing for assemblies still exists. Based on this I would suggest that you ideally:

  • Only use signed assemblies from a trusted publisher.
  • Use strong name references in your projects (which binds the project/assemblies to a specific public key).
  • Verify the signature for each assembly you download.

Possibly another concern is that a NuGet packages can have PowerShell install/uninstall scripts attached to it which are automatically run when using the NuGet package command-line. NuGet 1.4+ does support code signing for PowerShell scripts so I would suggest leaving PowerShell execution policy to RemoteSigned.

Alternatively don’t use NuGet and download the .msi/.exe from an official release and verify the signature on the file.


Since everything from the CLR to 3rd party libraries will be distributed via NuGet in ASP.NET vNext, the NuGet team has committed to supporting signed packages by, I believe, the time Visual Studio 2015 is released.

See the blog announcement: http://blog.nuget.org/20150203/package-signing.html

Also, see the signing spec: https://github.com/aspnet/Signing/blob/dev/Spec.md


Nuget now supports Package ID Reservation (see also Press Release)

This allows for additional trust between the developer and producer, but also is a step in the right direction for trust for Continuous Integration (CI) builds (since deterministic builds aren't possible in .NET)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .