[Epic] NuGet Package Vulnerability Auditing

[anangaur]

The NuGet team is following a know, prevent, fix framework to be proactive and take preventive measures to avoid security problems such as known vulnerabilities. This can be described as the following:

1. Know about the vulnerabilities in your software
2. Prevent the addition of new vulnerabilities
3. Fix or remove vulnerabilities.

The following work below represents each of these categories.

Know your vulnerabilities 👀

• Auditing projects for package vulnerabilities during restore #12310
• Package Status Indicators in Visual Studio Solution Explorer #11838
• Flow deprecation and vulnerability info into search service NuGetGallery#7297
• Show vulnerability/deprecation badges on packages in the details tab of the PM UI #12506
• Show vulnerabilities in transitive packages for PackageReference type projects in PMUI #8756

Prevent new vulnerabilities ⚠️

• [Feature]: Show which package versions are vulnerable in the VS PMUI package details pane version dropdown #11127
• Deprecation and vulnerability filters on Installed tab #9660
• [Feature] Warn for package operations that install/update a package with known vulnerability/deprecation metadata #13141
• [Feature]: When uploading a package, warn package authors when a known vulnerability is detected through package verification NuGetGallery#9436

Fix or remove vulnerabilities 🔧

• dotnet audit & dotnet audit fix for NuGet packages. #11549
• Show a Visual Studio notification when a vulnerability is detected #12399
• Show an infobar in Solution Explorer for any detected security vulnerabilities in a project or solution #12398

Please 👍 or 👎 this comment to help us with the direction of this epic & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.

Further tracking issues will be created shortly as requirements are gathered and planned.

[pascalberger]

Are there plans to support writing the output of dotnet list --vulnerable into a machine readable file? This would allow to use this command in scenarios like during a CI build, to block introducing packages with known vulnerabilities.

[pascalberger]

Who are the customers
All .NET Core customers.

Why are only .NET Core customers the target audience for this? Are there any technical restrictions why it does not work for .NET Framework projects? Will it be only PackageReference or also packages.config projects?

[anangaur]

Great questions @pascalberger. We should be making this info available to nuget.exe or msbuild.exe or both. We did discuss this but looks like we failed to mention it in the spec. /cc: @xavierdecoster

[zkat]

My main concern with this spec as-is is that it focuses so much on the informational aspect. When designing npm audit, our hypothesis was that it was much more important to make sure customers had specific actions they could do right away. Being informational tends to risk something becoming just plain noise that they'll tune out, and it doesn't result in people driving towards a more secure ecosystem. What's the expected workflow for people being able to pick non-vulnerable packages, once they're informed? For example, I wrote npm audit fix and it was available immediately after initial launch.

[anangaur]

@zkat This is definitely on the cards as part of Stage 2 where we plan to implement an audit or equivalent command. Thanks for bringing this up! I have added a line in the spec to indicate we do want to have a way to fix as well.