NPM Package Vulnerabilities and Effective Auditing
npm Package Vulnerabilities and Effective Auditing
Seen scary vulnerability alerts when coding with npm packages? With new issues discovered in popular packages all the time it’s easy to wonder whether your JavaScript apps are actually secure. The difficulty is determining which vulnerabilities actually matter, which packages are safe for release, and what really needs developer attention.
Running npm audit surfaces these issues, but also leads to a bunch of questions:
- Does “Low severity” mean it’s safe?
- How about “High severity”, just how severe is it?
- What should we do about it? Do I even need to do anything at all?
In this article, we’ll take a look at npm package vulnerabilities, how auditing works, and how organizations can manage them effectively at scale. I’ll then explain how to use ProGet to handle your vulnerability management to prioritize the threats that need urgent remediation and reduce the mountain of minimal-risk alerts.
Understanding npm Package Vulnerabilities and Auditing
npm package vulnerabilities are security weaknesses identified in JavaScript packages and reported to a central database, like the GHSA, NVD and CVE. For example, the “jQuery” package has a vulnerability related to “Object.prototype pollution”:
Not every package vulnerability is the result of unintentional coding flaws, and are deliberately injected malicious code. When you run npm audit, you’ll get a list of these vulnerabilities and what package versions they affect:
Remember that this only compares your npm packages against a database of reported vulnerabilities, not every vulnerability a package could have. This isn’t some kind of “virus scanning” and doesn’t guarantee your packages are free of vulnerabilities. By default, this command only checks registry.npmjs.org, so vulnerabilities that exist only in other databases won’t be reported.
For the ones that do show up, the severity of these vulnerabilities doesn’t always reflect how you should handle them. Even though jQuery has a high severity score, it’s likely not a risk inside your applications. Imagine someone injecting a crafted payload, potentially manipulating the object.prototype and compromising your application’s integrity. If your application is protected behind your firewall, you won’t need to worry too much.
Most vulnerabilities aren’t 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, How Can We Handle npm Package Vulnerabilities?
First things first, don’t just mindlessly upgrade everything! Instead, your organization should establish scalable vulnerability management that includes:
✅ Regularly monitoring packages you use in production for updates
✅ Routinely monitoring security advisories like GHSA and NVD
✅ Using automated scanning tools to identify new package vulnerabilities
✅ Intentionally assessing npm vulnerabilities based on the real risk and impact they pose to your applications, instead of relying only on severity scores.
Not all package vulnerabilities detected pose a real-world threat to your environment, but upgrading could introduce new vulnerabilities or regressions in your apps.
However, as projects scale, you’ll be pulling in more dependencies, and seeing more vulnerability alerts. It can make the decision to upgrade feel unavoidable. After all, the only other option would be to ignore them right? You’d be surprised at how many developers take this route when the mountain of alerts becomes overwhelming, with the limited info leaving them at a loss for next steps. Alert fatigue sets in quick when devs find themselves inundated with vulnerability notifications, with no way to suppress the noise.
For example, if you were to blindly upgrade jQuery to the latest version, you might end up with production errors due to how the new version serializes objects. But while sticking with any pre-3.4.0 versions of this package leaves you with vulnerabilities that pose minimal risk, ignoring alerts isn’t a mindset you’ll want to apply to every package, especially when they’re potentially exploitable in your applications.
What’s more, you can’t just rely on the npm client’s built-in scanning. There’s simply no guidance for resolving detected npm vulnerabilities, and the implied advice is to just upgrade, leaving you with a heap of alerts, and no information on what needs prioritizing.
It’s the lack of context that’s the problem. When every vulnerability is treated with equal urgency, real risks fall by the wayside. In reality, the risk of exploitation and impact can vary significantly depending on how a package is used. So, instead of reacting reflexively, it’s better to evaluate each case on it’s own merits.
💡 Evaluate npm Package Vulnerabilities Case by Case
Instead of always upgrading, determine if the vulnerability can be worked around or simply ignored. The reported vulnerability might not impact your application.
Will there every be an opportunity for a malicious actor to take advantage of this vulnerability? What are the consequences of a Denial-of-Service attack on our application?
While the built-in npm vulnerability is helpful, it shouldn’t be your sole source of info. Combine data from various sources, such as National Vulnerability Database and Inedo Security Labs, and conduct independent assessments of each package in the context of your applications.
💡 Maintain Consistency in Your Assessments
In large organization’s, vulnerability assessments need to be both repeatable and clearly documented. Think about it: an assessment is someone’s subjective take on a vulnerability as a given point in time, and evolving threats and personal knowledge can even alter an individual’s judgement over time.
Why Vulnerability Management Becomes Difficult at Scale
So, manually assessing npm package vulnerabilities takes time and effort. For each vulnerability you’ll need to:
- Research potential risks and how they apply to your applications
- Decide on what course of action to take
- Communicate this information to the rest of your team (or your future self)
These steps prevent redundant work when the same vulnerability appears again, but if you’re facing hundreds of vulnerability alerts for your latest build, performing manual assessments quickly becomes an insurmountable task. Devs can spend too much time reviewing vulnerabilities that pose little impact, and it soon becomes harder to tell what vulnerabilities need to be prioritized, and what can safely wait until the next major release to be fixed.
With all this effort in mind it’s easy to give up and think should I just not bother at all?
No! You should still scan your packages and evaluate the reported vulnerabilities on a case-by-case basis. Sure, most vulnerabilities present no real risk, but do you really want to that one bad package slipping through?
That’s where ProGet’s automated vulnerability management can help, taking much of the manual work out of the process, by highlighting what vulnerabilities your teams need to focus on, while suppressing the noise from the hundreds that they don’t.
Vulnerability Management in ProGet
As teams and projects grow, it’s easy to end up with thousands of packages, and consequently, thousands of vulnerability alerts. Keeping track of and assessing all these known and newly discovered vulnerabilities quickly becomes unmanageable, especially when developers don’t know which alerts are real risks that need prioritizing, and which alerts are just noise.
ProGet helps you suppress the noise, automatically identifying and categorizing the vulnerabilities in your builds, so you know which ones need handling with urgency. It can also suppress noisy alerts, so teams can focus on the vulnerabilities that matter, instead of fatiguing from having to triage hundreds of vulnerabilities manually.
By comparing vulnerabilities against our aggregated database of vulnerability records and categorizing them from 1 to 5 to indicate remediation urgency. From category 1 vulnerabilities which pose minimal real-world risk and are safe to address in a major release, to category 5 vulnerabilities which require immediate attention, ProGet lets you know when to upgrade:
But teams can’t solely rely on automation. Alerts still need to be investigated, researched, and assessed by devs when a risk is identified. You just don’t want to be trawling through thousands of alerts every times, so ProGet lets you change the emitted severity of vulnerabilities, suppressing the noise from alerts posing minimal risk:
This lets you control what alerts appear in the NuGet CLI, highlighting the risks that truly need attention, while preventing those that can be ignored from distracting developers.
Take React-Router 7.12.0. This package contains an open redirect vulnerability, which if service outages, data breaches, and data tampering are disruptive risk factors within your environment, can pose a serious threat:
But for applications where these risks are tolerable, the vulnerability carries minimal real-world risk:
If a vulnerability is truly risky in your environment, being swamped in alerts can easily pull dev focus away from these true threats. Suppressing alerts prevents noise from minimal risks from drowning out the vulnerabilities that need urgent remediation.
Conclusion
As your org grows, vulnerabilities shouldn’t be a concern to your apps as long as you know what to do. It’s about assessing vulnerabilities case-by-case based on their potential risk and impact in your environments, and ensuring focus is kept to the real risks, instead of burning out fighting against a tirade of minimal-risk alerts.
Individual vulnerabilities need to be assessed with intention over mindless upgrading, and ProGet’s categories and noise suppression lets devs know where to look, making sure the risky vulnerabilities are the ones addressed.
To keep your builds consistent, preventing dependency drift is key, so start leveraging lock files in your npm packages, which we cover in the next article, Handling Dependencies in Lock Files.