This article is part of our series on NuGet at Scale, also available as a chapter in our free, downloadable eBook.

When you’re working with NuGet packages as part of your .NET applications, it can be frustrating to run a package audit and see vulnerability warnings pop up. New issues in popular packages come up constantly, so you’re forgiven for worrying about how secure your app really is. Even if you’ve used the NuGet or dotnet CLI to scan for vulnerabilities, figuring out which packages are safe for production and what needs attention can quickly become a headache.

Scanning NuGet.org could return several vulnerability warnings, and lead to a bunch of questions: How do I manage them? Does a “Low severity” mean it’s safe? How about “High severity”, just how severe is it? Can I explain what this means.. or how it affects my code? What should we do about it? Do I even need to do anything at all? 

It’s a lot to consider! In this article, I’ll explain NuGet vulnerabilities, how scanning works, and how organizations can manage them effectively at scale. I’ll then talk about using ProGet to handle your vulnerability management with features like assessment rules and download blocking to resolve your NuGet vulnerabilities.

What Are NuGet Package Vulnerabilities and Scanning Exactly? 

NuGet package vulnerabilities are security weaknesses discovered in .NET packages and reported to a database like the GHSA, NVD and CVE. For example, Newtonsoft.Json has a vulnerability concerning “Improper Handling of Exceptional Conditions”:

Expressions with high nesting level that lead to StackOverFlow exception or high CPU and RAM usage. can lead results in Denial Of Service (DoS)

https://github.com/advisories/GHSA-5crp-9r3c-p9vr

NuGet package vulnerabilities can pose serious security risks. In some cases, such as the well-known incident where multiple popular packages were compromised, these risks aren’t just accidental flaws but deliberately injected malicious code. When you run dotnet list package --vulnerable or nuget audit you’ll get a list of these vulnerabilities and what package versions they affect.

Keep in mind, this just compares your NuGet packages against a database of reported vulnerabilities, not every vulnerability a package could have. This isn’t some kind of “virus scanning” nor does it “eliminate all vulnerabilities”. What’s more, it only scans a single database (GitHub Advisory Database), so vulnerabilities reported in other databases won’t show up.

But it’s a lot better than nothing! Even so, the “severity” of these package vulnerabilities doesn’t reflect how you should handle them. For example, even though the Newtonsoft.Json vulnerability from earlier is a “High” severity, it probably won’t be a real risk for your applications.

Quite high nesting level (>10kk, or 9.5MB of {a:{a:{... input) is needed to achieve the latency over 10 seconds, depending on the hardware.

Wait… a 9.5MB malicious JSON document!? For an application sitting behind your firewall, that’s probably not a real worry. The rated Severity doesn’t up the chance of exploitation or the impact on your application. 

Most vulnerabilities are not easily exploitable. If they require specific access rights or aren’t accessible through typical user interactions, the risk of exploitation is close to zero.

So, What Can We Do About NuGet Package Vulnerabilities? 

First things first, don’t just mindlessly upgrade everything! Instead, your organization should establish scalable vulnerability management that includes:

It’s all about a balance. Like I was saying, mindlessly upgrading when new updates are available isn’t a great idea as not all package vulnerabilities detected are a threat to your code. However, upgrading could introduce unknown vulnerabilities or cause other regressions or issues in your application.

What’s more, you can’t just rely on the NuGet client’s built-in scanning. There’s simply no guidance for resolving detected NuGet vulnerabilities, and the implied advice is to just upgrade by default. For example, if you were to blindly upgrade NetwtonSoft.Json to the latest version — you might end up with production errors because of how the new version deserializes objects.

💡 Assess NuGet Package Vulnerabilities Case-by-Case

Instead of always upgrading, first, determine if the vulnerability should be worked around or simply ignored. The reported vulnerability may simply not impact your application.

Will there even be an opportunity for a malicious actor to inject a 9.5MB JSON file? What are the consequences of Denial-of-Service attack on our application?

While the built-in NuGet vulnerability feature is helpful, it should not be your sole source of information. Combine data from various sources and conduct independent assessments of each package.

💡 Be consistent in your Assessments

In large organizations, vulnerability assessments need to be repeatable and clearly documented. If you think about it, an “assessment” is basically someone’s personal judgment and their subjective take on the vulnerability’s severity at that time.

What one person considers “critical”, another might see as less important. Even if it’s one person doing multiple scans, evolving threats or personal knowledge growth can alter their judgment over time. 

Should I Just Not Bother With Vulnerability Scanning?

Assessing vulnerabilities in NuGet packages is time-consuming and labor-intensive: you have to manually go through every vulnerability one-by-one, look them up, determine potential risks, and then decide how to deal with them. And then you have to somehow communicate this with the rest of your team (or your future self), so you don’t have to do the same work the next time the same vulnerability comes up.

This will eventually lead to review fatigue that may result in neglecting vulnerabilities that require thorough assessment.

So should I just not bother at all?

No! You should still scan your packages and assess the reported vulnerabilities on a case-by-case basis. Sure, most vulnerabilities have no real risk — but do you really want that bad package slipping through? Fortunately, ProGet’s automated vulnerability management can make this very easy, making large-scale vulnerability management far more sustainable.

How ProGet Can Optimize Your Vulnerability Assessments 

ProGet‘s automated vulnerability assessments and download blocking, can significantly optimize the effectiveness of your NuGet package vulnerability management. 

⚙ Assessment management allows you to configure different types of assessments (block, ignore, caution, etc) and log comments so that everyone can follow and understand the decisions made.

⚙ Automated vulnerability assessment allows you to create rules based on the reported severity (low, medium, critical, etc.), so that you don’t have to react the moment a new vulnerability is reported; you can always apply judgment and edit the auto-assessment later

⚙ Download blocking can ensure that only approved packages are used. This reduces potential vulnerabilities and communicates a clear message to developers. It will prevent their use of specific packages, causing an error if they attempt to download them again. 

⚙ Custom Assessments mean that audit results reflect your team’s own assessments. So vulnerabilities you’ve assessed as “Ignore” won’t show up in the list, or one’s you’ve marked one as “Blocked” will show up as “Severe” issue, even if the public advisory says it’s only “Moderate” or “High”. Basically, you see the severity you care about, not just what someone else decided.

Additionally, ProGet comes bundled with ProGet Vulnerability Center. PGVC is a constantly updated offline aggregation of leading vulnerability databases, including GSHA and the Global Vulnerability Database. No longer do you need to worry about constantly having to monitor various vulnerability databases, as everything is in one place. 

Take Control of Your NuGet Package Vulnerability Management

As your development organization grows, vulnerabilities shouldn’t be a concern to your applications as long as you know what to do:

💡 Learn to assess vulnerabilities not only by severity but potential risk and impact

💡 Make informed decisions and determine how to react to vulnerabilities identified

This will involve individual package assessment over just mindless upgrading. ProGet can help you assess vulnerabilities consistently and reliably by introducing automated assessment against an aggregated, offline database of vulnerabilities. 

This will be a lot to remember, so I recommend saving it somewhere or bookmarking it. If you want even more on NuGet in your organization, grab our free eBook, “NuGet at Scale”. It’s got everything we just covered, plus it’s packed with valuable insights on packages at scale, challenges with CI/CD, and much more! Download your copy now!