[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.

[anangaur]

@skofman1 This should be the epic issue that should link any intermediate issues tracking the feature. Can you help me in linking the in-progress and planed items here from https://github.com/NuGet/nugetgallery/ or anywhere else?

[skofman1]

@anangaur , converted this to an epic and linked the Gallery epic to it.

[anangaur]

Tagging folks from community who have similar tools in the space to get their comments, feedback on the proposed experience:

• dotnet-retire: @johnkors
• SafeNuGet: @eoftedal
• DevAudit: @allisterb, @kenduck
• NuGetDefense: @digitalcoyote

It will be great to get your perspective on this feature. As you will notice, the feature is divided into 2 parts/phases:

• Phase 1 is informational in nature that provides vulnerability information to package consumers when they seek it. This spec is for Phase 1.
• Phase 2 is going to be more involved experience which will let consumers know whenever they have a vulnerable package in their package graph (may be as part of package restore) and a one-click/one-command way to fix the package graph. This needs more clarity.

[johnkors]

Thanks for pinging. Here's a summary of what has arised in the dotnet-retire issue tracker, and my 2 cents for features around the topic. I haven't really looked into what fits with phase 1/2 or future, so just treat it as some thoughts.

Exit codes

Use a meaningful exit code for this to run as part of a build in CI, so one has the option to fail the build easily.

Console/terminal format

Human readable format in the console, with a full dependency chain shown in case of transient vulnerabilities so they are

1. understandable
2. actionable

As a developer, it should be clear: "ok, I need to update this top-level dep, or install this transient as a direct dep from this version to this version".

Report formats

For the output format, there are many standards, including SWID, SPDX, CycloneDX, Package URL, and others. Look into those. See this article.

Choosing a standard format, would make it easier for monitoring tools to import, examples:

• https://dependencytrack.org/
• https://www.meterian.com/

.NET specific handling:

• Over the last years, there has been packages being moved from being released to nuget.org, to be part of the shared framework instead. These need special handling depending on TFM.
• It should work on the sln level (scan all projects part of sln), as well as on the project level (scan specific project)
• Multi-targeting support (probably just a output question, is showing a dependency vulnerability necessary for each TFM?)

Other features:

• Bringing your own feed/marking your own set of Nugets. It should be possible to bring your own feed/ mark internal packages as vulnerable. (dotnet-retire does this)
• Being able to not only run the scan/audit as CLI cmd, but for example as a MSBuild task as well (NuGetDefense does this)
• Being able to run behind corporate proxies
• Reporting on vulnerable runtimes. With more and more nugets being moved into the shared framework, more of the security patches will be by hands of patching runtimes. For dotnet-retire, I setup a component that checks the release feed ex. for 3.1 for recent security patches and logs a WARN about using a vulnerable runtime using the configured logger for a given .NET Core host. Many ways around exposing this from a running .NET host, but my feeling is that the runtime audits are as important as the audits being done at restore/build time.
• Flagging .NET Global Tools, for example ("You're trying to install tool X, and it has these known vulns . Do you want to continue?")

Another aspect: In case of larger API sets of a vulnerable library, it might be that the consumer is only using the unaffected parts.

[digitalcoyote]

Building on @johnkors response:

Output

Output should give all the information a developer needs to take action on the vulnerability and if at all possible, be configurable. If developers start ignoring output the battle is lost.

• Verbosity, some will like a wall of text, others will ignore everything if the output is too long.
• Dependency vulnerability information - In the event that dependencies have vulnerabilities, but a specific package does not, the dependent package should still be listed as vulnerable, but make it clear that it's dependencies have vulnerabilities.
• Include the affected version range.

Custom Vulnerability Feeds

NuGet supports custom feeds that may include packages for which there are only internal sources that cover their vulnerabilities. Having a standard for obtaining these that could be implemented by third-parties to provide that data. This can also help when bandwidth is an issue.

Offline Support/Caching

A number of issues could be resolved with an offline cache of vulnerability data. NuGetDefense provides a cache like this containing data from NVD (ends up being < 30MB).

Dependencies and Frameworks

A multi-target package may have dependencies for .Net 4.8 that are not present in .Net Core 1.0 or .Net Standard 2.1. NuGet should be able to resolve the correct vulnerabilies and vulnerabilities of dependencies for the target framework.

Ability to Ignore Vulnerabilities

This leans on the idea from earlier. If they feel they need to ignore part of the output, they may start ignoring all of it.

• Packages may have vulnerabilities that do not affect the project because that part of the package is not used.
• They may only be concerned with specific severity or attack vectors.

[anangaur]

Thanks @johnkors, @digitalcoyote for detailed comments and suggestions. Super helpful.

/cc: @drewgillies

[drewgillies]

Yes--thank you!

[philipahlberg]

Exit codes

Use a meaningful exit code for this to run as part of a build in CI, so one has the option to fail the build easily.

This would be very helpful, but it seems like it wasn't implemented. Why not?

[freerider7777]

dotnet list package --vulnerable does not warn about netcoreapp2.2 projects not supported?
It seems some CVE are not fixed for 2.2 as they appear after end of support like dotnet/aspnetcore#25701

[ericstj]

@anangaur make sure you consider false positives in packages which might be part of the NuGet package graph, but will be removed by the SDK conflict resolution cc @dsplaisted. This is the way we handled packages which were "absorbed" by frameworks since there is no way to express to NuGet to not download them if they are dependencies of packages. Since these packages are dead-ended it's very likely they will be old and potentially be marked vulnerable. Those vulnerabilities would never impact the application since the SDK would remove the package assets.

Alternatively you can add functionality to NuGet to tell it which packages are "provided by" the framework and avoid that download / conflict-resolution step entirely.

[anangaur]

Adding @JonDouglas who owns this feature.

[JonDouglas]

@ericstj We'll revisit this shortly. I believe the latter option is what we're hoping to improve on in terms of in-the-box vs. out-the-box dependencies. We don't detect packages provided by framework today and will need to work with SDK team on that scenario.

[kapsiR]

Since the planned package audit features are going in the right direction 👏👍, are there any plans to actively help putting vulnerability information into the system? (server side)

One pretty famous example in my opinion is the recent event with a very outdated curl package:
https://daniel.haxx.se/blog/2023/03/02/the-curl-nuget-story/

[JonDouglas]

@kapsiR This is a very complex topic. I hope to write a blog shortly talking about some of the challenges here.

NuGet is an intermediate. We use a centralized supplier known as the CVE (list of publicly disclosed vulnerabilities) through GitHub Advisories. For libraries like Curl, they maintain a thorough list of CVEs.

As you may imagine, the challenge here happens when a package derives another and whether it is actually maintained or not. NuGet being an intermediate, we do not issue CVEs. We rely on a CNA(CVE Numbering Authority) to do so on behalf of the reporter and the maintainer of a package who becomes aware of a vulnerability.

When we become aware of any vulnerability, we tend to bridge the connection of the reporter and the maintainer to take action and our due diligence on behalf of the community.

If you have ideas for how we can bridge this gap further, please do file another issue with more details. We rely on the effort of our maintainer ecosystem to stay current with known vulnerabilities and ensuring each CVE has high-quality data. If you suspect any other notable libraries and their NuGet derivatives may contain known vulnerabilities, please reach out to the maintainer and send us a support request so we can be aware of it if they are unresponsive.

[JonDouglas]

Hi folks,

Much of this work was released with NuGet 6.8:

https://devblogs.microsoft.com/nuget/announcing-nuget-6-8-maintaining-security-with-ease/

We may need to re-organize this issue with our plans going into next year. You can also view our documentation for auditing experiences here:

https://learn.microsoft.com/en-us/nuget/concepts/auditing-packages

I will likely work with the team to create individual epics based on the new work areas we have started such as auditing at restore time, auditing affordances in tooling, and security enhancements made to NuGet gallery. Thus we may close this to better track work long term on an area basis. This epic might be too large right now to know what's actually happening.