NPM
Exploring npm Package Vulnerabilities and Effective Auditing
This article part of a series on Mastering npm in the Enterprise, also available as a chapter in our free, downloadable eBook
Seen scary vulnerability alerts when you’re coding with npm packages? Worried about the security of your JavaScript apps due to the latest scare, like when several widely used JavaScript libraries were compromised? If you build JavaScript apps, you rely on npm for managing dependencies. And over time, some of those dependencies will inevitably have vulnerabilities.
Tools like npm audit surface those issues, but they don’t tell you what actually matters for your application. Instead, you’re left with a long list of warnings and a lot of uncertainty:
Are “low severity” issues safe to ignore?
What do “high severity” vulnerabilities actually mean in practice?
Do they affect your code at all? And if they do… what are you supposed to do about it?
In this article, we’ll take a look at npm package vulnerabilities, the auditing process, and the challenges you have to deal with. I’ll also cover what you should know when handling vulnerabilities and how ProGet’s tailored vulnerability guidance can help inform you of the best steps to take for your apps.
Understanding npm Package Vulnerabilities and Auditing
npm vulnerabilities are security weaknesses identified in JavaScript packages and reported to a central database. For example, the “jQuery” package has a vulnerability related to “Object.prototype pollution”:
These kinds of vulnerabilities pose potential security risks. Running npm audit gives you a list of vulnerabilities and the affected package versions, but it only gives you an overall severity rating for your package dependency, using the highest returned severity (“critical”, “high”, etc… ). This makes it hard to figure out which vulnerabilities need your immediate attention.
Keep in mind, an audit only compares your npm packages against a database of reported vulnerabilities. Bottom line is, it’s not a comprehensive “virus scan”, nor does it eliminate all vulnerabilities. What’s more, it scans only one database (GitHub Advisory Database), so vulnerabilities reported elsewhere will not be detected.
What’s more, the “severity” ratings of these vulnerabilities shouldn’t solely be used to decide how you respond to them. Severity assumes a worst case scenario, one which might not even be applicable in the context of your apps. For example, even though the “jQuery” vulnerability we looked at has a “Moderate” severity rating, there’s not much risk to using it.
Imagine someone injecting a crafted payload, potentially manipulating the Object.prototype and compromising your application’s integrity. If your application’s protected behind your firewall, you won’t need to worry too much. The severity rating doesn’t account for the likelihood of exploitation or the impact on your specific application.
Most vulnerabilities are not easily exploitable. If they need particular access rights or aren’t accessible through regular user interactions, the risk of exploitation is trivial. It’s important to assess context when deciding how to address vulnerabilities, especially when the audit gives you an overall severity rating without individual details.
So, How Can We Handle Vulnerabilities?
First and foremost, avoid just blindly upgrading your packages. Instead, consider:
✔ Regularly monitoring packages used in production for updates
✔ Routinely checking security advisories like GitHub Advisory Database (GHSA) and NVD
✔ Employing automated scanning tools to identify new vulnerabilities
✔ Evaluating vulnerabilities based on actual risk rather than solely on severity
Mindlessly upgrading whenever new updates are available isn’t the best move. Not all detected vulnerabilities pose a threat to your code
However the updates themselves could introduce unknown vulnerabilities or screw with your application. Case in point, if you were to blindly upgrade “jQuery” to the latest version, you might encounter production errors because of changes in object deserialization.
What’s more, you can’t just rely on the npm client’s built-in auditing. You’re not getting guidance on how to resolve detected vulnerabilities. The implied advice is, you guessed it —just to upgrade. Again, this might do more harm than good.
💡 Evaluate Vulnerabilities Case by Case
Instead of always going down the upgrade route, start by determining if a vulnerability needs mitigation or can be safely ignored. The reported vulnerability may not have much of an impact on your application.
Will there be a realistic opportunity for a malicious actor to inject a crafted payload and exploit Object.prototype? What are the potential consequences of a Denial-of-Service attack on our application?
While the built-in npm vulnerability auditing feature is valuable, it shouldn’t be your only source of information. Combine data from different sources and conduct independent assessments of each package, and remember, your individual context is what’s key.
💡 Maintain Consistency in Your Assessments
When you think about it, an “assessment” is basically someone’s subjective judgment of a vulnerability’s severity at a given time. But what one person considers “critical,” another may not regard it as serious. Even if one person conducts multiple scans, evolving threats or increased knowledge can alter their judgment over time.
If you’re going to assess your vulnerabilities efficiently, you’re going to have to figure out how to keep things consistent.
Should I Just Skip Vulnerability Scanning Altogether?
Assessing vulnerabilities in npm packages can be time-consuming and labor-intensive. You have to systematically review each vulnerability, research potential risks, and determine appropriate responses. Added to that, you must communicate this information to your team (or your future self) to avoid repetitive work when similar vulnerabilities crop up in the future. This is going to lead to review fatigue, leading to overlooking vulnerabilities that need a more thorough assessment.
So, should you skip vulnerability scanning entirely?
No! You should still audit your packages and evaluate reported vulnerabilities on a case-by-case basis. While most vulnerabilities may pose no real threat, do you really want to risk a problematic package slipping through the cracks? Thankfully, automated scanning tools can simplify this process significantly!
How Scanning Tools Can Enhance Your Vulnerability Assessments
Automated scanning tools, such as ProGet can greatly enhance the efficiency of your vulnerability management:
⚙ Assessment management allows you to configure different types of assessments (block, ignore, caution, etc.) and document comments, ensuring that everyone can follow and understand the decisions made.
⚙ Automated vulnerability assessment allows you to establish rules based on the reported severity (low, medium, critical, etc.), reducing the need for immediate reactions to new vulnerabilities. You can later apply judgment and modify the auto-assessment as needed.
⚙ Vulnerability categorizations, using the ProGet Vulnerability Remediation Scale, provide vulnerability guidance based on organizational or operational profiles you configure, meaning you receive tailored guidance on whether to remediate now, later, or never, based on the context of your apps.
⚙ Download blocking can enforce the use of approved packages only, minimizing potential vulnerabilities and clearly communicating this requirement to developers. Attempting to download unapproved packages would result in errors.
⚙ Integrated native npm audit support uses ProGet’s vulnerabilities and assessments removing the need for developers to have to handle this themselves, making things even more efficient!
Now running npm audit will also link users to details of the vulnerability in your own ProGet instance, allowing you to leave comments regarding the vulnerability for your team to see.
Additionally, ProGet is bundled with the “ProGet Vulnerability Center” (PGVC), an up-to-date aggregation of prominent vulnerability databases, including the GitHub Advisory Database (GHSA) and the Global Vulnerability Database. You no longer need to continuously monitor various vulnerability databases, as all the data is conveniently consolidated.
Take Control of Your npm Vulnerability Management
Vulnerabilities shouldn’t be a significant concern for your applications as long as you take the following steps:
💡 Learn to assess vulnerabilities based on their potential risk and impact, not just their severity.
💡 Make informed decisions regarding how to address identified vulnerabilities.
This means evaluating individual packages and considering how vulnerabilities will affect your apps, instead of blindly upgrading. ProGet can help you maintain consistent and reliable vulnerability assessments by providing automated assessments against a consolidated, offline vulnerability database.
That was quite a bit to cover, and I’d suggest keeping a handy summary of it for future use. Why not sign up for our guide, Mastering npm in the Enterprise. It includes more on managing vulnerabilities, as well as managing packages and optimizing workflows in your organization, and much more. Sign up for our free copy today!
