NPM
Exploring npm Package Vulnerabilities and Effective Auditing
Seen scary vulnerability alerts when you’re coding with npm packages? Worried about the security of your JavaScript apps due to the latest exploit scare? When you build JavaScript apps, you often use npm packages for managing libraries. Keeping these packages safe for production is super important.
I’m guessing you probably run npm audit to check your packages, right? Auditing your npm packages, you’ll find lots of security warnings. It makes you wonder: How do you fix them? Are “Low severity” warnings no big deal? And what about the scary “High severity” ones? How do they affect my code? Do I even need to do anything about them?
It’s a lot to digest. In this article, we’ll take a look at:
- npm package vulnerabilities and the auditing process
- The challenges you have to deal with
- What you should understand to make informed decisions
- How to sort out your vulnerabilities
Understanding npm Package Vulnerabilities and Auditing
npm vulnerabilities are security weaknesses identified in JavaScript packages and reported to a central database. For instance, the “jQuery” package has a vulnerability related to “Object.prototype pollution”.
Such vulnerabilities pose potential security risks. Running “npm audit” provides a list of vulnerabilities and the affected package versions, but it only offers an overall severity rating for your package dependency, using the highest returned severity. (“critical”, “high”, etc… ) This makes it difficult to identify which vulnerabilities demand immediate attention.
Keep in mind that an audit merely 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.
In any case, it’s a significant step toward improving security. However, the “severity” of these vulnerabilities shouldn’t dictate your response. For instance, even though the “jQuery” vulnerability we looked at has a “Moderate” severity rating, there’s not much risk to using it.
Now, consider someone injecting a crafted payload, potentially manipulating the Object.prototype and compromising your application’s integrity. For an application 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 application.
Most vulnerabilities are not easily exploitable. If they need specific access rights or aren’t accessible through regular user interactions, the risk of exploitation is trivial. It’s crucial to assess the context when deciding how to address vulnerabilities, especially when the audit provides 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
It’s all about that zen balance. Mindlessly upgrading whenever new updates are available isn’t the best move, as not all detected vulnerabilities pose a threat to your code. One thing they could do though is 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 due to changes in object deserialization.
What’s more, you can’t rely solely 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 requires 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 sole source of information. Combine data from various sources and conduct independent assessments of each package.
Maintain Consistency in Your Assessments
When you think about it, an “assessment” is essentially someone’s subjective judgment of a vulnerability’s severity at a given time. But what one person deems “critical,” another may regard as less significant. 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 arise 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.
⚙ 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 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 instead of blindly upgrading. ProGet can help you maintain consistent and reliable vulnerability assessments by providing automated assessments against a consolidated, offline vulnerability database.
Vulnerability management is just a part of the broader landscape in npm development. Want to learn more? Why not sign up for our free npm in the Enterprise eBook today!
