Have you seen vulnerability warnings when working with NuGet packages? Or read about the latest vulnerability in a NuGet package, and are concerned about your .NET application’s security?

When you develop .NET applications, you most certainly will work with NuGet packages to manage libraries and dependencies. Making sure these packages are safe for production use is a crucial responsibility. Chances are you’ve also used the NuGet or dotnet CLI to scan all your packages. 

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 and package scanning 
• The issues surrounding them 
• What you need to know to make the right decisions
• How to resolve vulnerabilities 

What Are NuGet Package Vulnerabilities and Scanning Exactly? 

NuGet vulnerabilities are security weaknesses discovered in .NET packages and reported to a database. 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

Vulnerabilities like these pose potential security risks. When you run dotnet list package --vulnerable, you’ll get a list of these vulnerabilities and what package versions they affect.

It’s worth noting that this simply compares your NuGet packages against a database of reported vulnerabilities, not every vulnerability a package could have. In other words, it’s not “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! However, the “severity” of these 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 factor the likelihood 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 Vulnerabilities? 

First things first, don’t just mindlessly upgrade everything! Instead, you should: 

It’s all about a balance. As I mentioned, mindlessly upgrading when new updates are available isn’t a great idea as not all vulnerabilities detected may pose a risk 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 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 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

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 you 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, automated scanning tools can make this very easy! 

How Scanning Tools Can Optimize Your Vulnerability Assessments 

This is how automated scanning tools, such as ProGet, can significantly optimize the effectiveness of your 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. 

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 Vulnerability Management

Vulnerabilities shouldn’t be a concern to your application 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. 

Managing NuGet vulnerabilities is important, but there’s a lot more to learn about NuGet packages to successfully use them on the Enterprise level. Sign up for our mailing list to receive our upcoming guide that will guide you through everything NuGet!