How to Scan NuGet Packages for Security Vulnerabilities

Drew Gillies

Open Source is everywhere. It is in many proprietary codebases and community projects. For organizations and individuals, the question today is not whether you are or are not using open-source code, but what open-source code you are using, and how much.

If you are not aware of what is in your software supply chain, an upstream vulnerability in one of your dependencies can be fatal, making you, and your customers, vulnerable to a potential compromise.

Today, we are announcing the public availability of NuGet’s vulnerability features that you can use to ensure your projects are vulnerability free and if not, to take action to securing your software supply chain.

Where do CVE/GHSA come from?

NuGet gets its CVE/GHSA information directly from the centralized GitHub Advisory Database. The database provides two main listings of vulnerabilities:

  • A CVE is Common Vulnerabilities and Exposures. This is a list of publicly disclosed computer security flaws.
  • A GHSA is a GitHub Security Advisory. GitHub is a CVE Numbering Authority (CNA) and is authorized to assign CVE identification numbers.

Image 2021 03 01 9 33 15

See the following documentation on GitHub Security Advisories.

NuGet.org Package Details

You can now view any known CVE/GHSA directly on NuGet.org. NuGet.org will show you a banner telling you that a vulnerability with a specific severity has been detected and how you might go about resolving it.

Image 2021 03 01 10 03 52

For package authors, you will see a banner telling you that a specific package version had a vulnerability detected. You will be able to view the advisory, severity of the advisory, and any actions you should take to protect the NuGet ecosystem.

Image 2021 03 01 10 04 08

Additionally, you will see a warning icon of your listed packages to let you know that a vulnerability has been detected.

Image 2021 03 01 10 04 37

dotnet CLI

You can now list any known vulnerabilities in your dependencies within your projects & solutions with the dotnet list package --vulnerable command.

Image 2021 03 01 9 40 10

You will see any vulnerabilities within your top-level packages. You will be able to understand the version resolved, the severity of the advisory, and a link to the advisory for you to view.

If you are interested in seeing vulnerabilities within your transitive packages, you can use the --include-transitive parameter to see those.

Image 2021 03 01 18 26 59

To scan for vulnerabilities within your projects, download the .NET SDK 5.0.200, Visual Studio 2019 16.9, or Visual Studio 2019 for Mac 8.8 which includes the .NET SDK.

Note: Packages listed in examples above have since been patched or have been marked deprecated & unlisted appropriately.

Summary

You have learned about the new tools that NuGet provides to help you scan your NuGet packages for security vulnerabilities. These tools should help you secure your software supply chain and take action today.

Although this is the beginning of bringing a more secure package ecosystem to .NET developers everywhere, we have many exciting plans to help you audit & fix your dependencies in the near future.

If you’re interested in the best practices that you can follow today to secure your software supply chain, check out our documentation on best practices for a secure software supply chain.

27 comments

Discussion is closed. Login to edit/delete existing comments.

  • Juan Manuel Barahona 0

    This is absolutely cool! thanks for making this easy for us, I will definitely use this this on pipelines, and yes have an option that fix the vulnerabilities by bumping up the versions automatically would be great.

    • Drew GilliesMicrosoft employee 0

      Glad to hear it! It’s also good to hear about how useful a fix option would be–all of this input shapes our planning.

  • Pascal Berger 0

    Any plans to support writing the report into a machine readable format which can be further processed in CI pipelines?

    • Rehan Saeed 0

      +1 This would be awesome.

    • Francesco 0

      +1 would also be nice to support adding it to a build pipeline and let it fail if vulnerabilities are found

      • Curtis Carter 0

        NuGetDefense is adding this as a vulnerability source. If you have nothing but this scanner enabled, it will run this command after the build and warn/error if there are any vulnerable packages.

    • Drew GilliesMicrosoft employee 0

      It’s definitely something we’ve been talking about. It would be a good discussion to reintroduce in a public forum. We would definitely want to get this right, ensuring we have the most useful information presented to users of the CLI. Thanks for upvoting it, all.

    • Drew GilliesMicrosoft employee 0

      This has been an ongoing discussion for some time regarding dotnet list in general. Here’s the issue: https://github.com/NuGet/Home/issues/7752. Feel free to comment on it to give it more visibility. There are some thoughts here on output formatting for –outdated and –deprecated reports–it would also be good to get a sense of how the NuGet community would like to consume json (presumably) for –vulnerable reports.

  • Drew Freyling 0

    This is great news! Out of curiousity would say the npm lodash vulnerabilities that exist, shouldn’t they also apply to the nuget version as well?

    • Drew GilliesMicrosoft employee 0

      This is a good topic for us to explore. Currently we mine our vulnerabilities from GitHub, so what is not reported there is not reported here. But one topic of discussion is going more broadly with sources, and one area I’m interested in is how big a delta we are talking. Lodash would be a good topic of research, given that it shows us some of this delta. I intend to look into where npm has sourced this vulnerability and then look at researching further as planning proceeds. Thank you for raising this.

  • Tjeerd Menno Douma 0

    This is very usefull functionality.

    But unfortunately it does not work when using NuGet.org packages through an Azure DevOps Artifact feed (NuGet.org configured as upstream source).
    Any plans on supporting this?

    • Roger Noden 0

      +1

      We have an Azure DevOps Artifacts Feed, the dotnet list package –vulnerable command requires the user to run with “–interactive”; this then ends up creating a new Personal Access Token request for EVERY package in our feed. It doesn’t seem to cache or use the cache of tokens. This makes this unusable for our developers.

    • Drew GilliesMicrosoft employee 0

      These are both very valuable insights, and I want to replicate this case and see what can be achieved. Thank you so much for bringing it up.

      • Peter Tollnes Flem 0

        +1

        We have a Azure DevOps NuGet feed as well that’s behind auth.
        But great that this is out 🙂

      • Richard Deeming 0

        Another +1 for this.

        Running the tool with the “–interactive” flag prompts to open a web page and enter a code. But after completing the device flow and closing the page, the tool just displays the same message with a different code.

        I now have multiple personal access tokens added to my account, but the tool doesn’t seem to be able to use them.

  • Matthias Koch 0

    Important work! I just run this on my solution and I got the feeling that it isn’t working very “smart”. It processed the first project which basically references all other projects from the solution, yet all the other projects were inspected again (and again if referenced from another once more).

    • Matthias Koch 0

      And a side-note, your blog shows times in PDT although I’m in CET.

    • Drew GilliesMicrosoft employee 0

      This may be the way the CLI has functioned historically, and could be a good issue for us to look at–would you please file it here (https://github.com/NuGet/Home/issues)? Once you do, please comment back here with a link to it, so I can keep an eye on it.

    • Drew GilliesMicrosoft employee 0

      Thank you! And Visual Studio Package Manager integration is something we’re currently working on. Stay tuned!

  • Christo 0

    This is great, thanks.

    • Drew GilliesMicrosoft employee 0

      You’re welcome, and thanks for the comment!

  • Peter Tollnes Flem 0

    Thanks for this! It’s great to have such a tool.

    When I run the dotnet list package --vulnerable command, it seems to use all NuGet sources that it knows of on my machine, even if they are not used in the current project I’m trying to scan. Is there any way to make it only use sources that are relevant to a project, other than manually specifying them with the --source option? It causes a problem when it can’t authenticate with a NuGet feed, even though the feed isn’t used in the project.

  • Peter Row 0

    Can this be used for projects that run on .NET 4.x or is it only for those using .NET Core?

    • Colac, Teodora 0

      Good morning! I have the same question, can this command be used for projects on .Net 4.7 ?
      I have the following error:
      “The imported project “C:\Program Files\dotnet\sdk\5.0.201\Microsoft\VisualStudio\v16.0\WebApplications\Microsoft.WebApplication.targets” was not found. Confirm that the expression in the Import declaration “C:\Program Files\dotnet\sdk\5.0.201\Microsoft\VisualStudio\v16.0\WebApplications\Microsoft.WebApplication.targets” is correct, and that the file exists on disk.”
      I have the sdk installed with VS 2019 16.9.2.

  • Wayne ~~ 1

    Is only for .Net Core ?

Feedback usabilla icon