Know Your Vulnerabilities
The biggest step to take in protecting your applications is mitigation, which starts with knowing what vulnerabilities you have in your app. The best way to do this is to understand the libraries you’re using, to keep your dependencies updated, and to regularly track advisories.
It’s important to make sure the libraries you’re using are regularly maintained and kept current. This can be a challenge, though, when you consider how libraries are typically built. Like legos, open source libraries are, more often than not, built on top of other libraries, which are composed of other libraries, and so on and so forth. Frequently, vulnerabilities actually come from these indirect dependencies, since the deeper you go, the harder it is to track and the harder it is to know if the indirect dependencies are maintained. But, by choosing up-to-date libraries for your app, you’ve already taken a step in the right direction.
You need to make sure you keep those dependencies as updated in your app as they are in their package managers. Make sure you regularly upgrade your packages (especially if the upgrade guarantees no breaks) and do this especially when there are notifications about hot-fixes and patches that handle vulnerabilities. This is where an open source vulnerability management solution like FOSSA can be of particular assistance.
Finally, don’t rely only on the package managers for a healthy app. Make sure you stay on top of the advisories as well. Use and learn from Open Web Application Security Project® (OWASP), CWE, National Vulnerability Database (NVD), and other sources to stay on top of the biggest threats, and be aware of bulletins issued by the vendors whose products you’re using. Node.js, for example, offers an extensive bulletin notifying of their vulnerabilities and available fixes.
Most important is to remember: The more proactive you are, the safer your apps are.
Prioritize Your Vulnerabilities
Vulnerabilities exist everywhere, to such an extent that dealing with them can feel overwhelming. It’s very difficult — and in some cases nearly impossible — to address every single one of them, which is why it’s so important to prioritize. To help do this, you can use the Common Vulnerability Scoring System (CVSS) scoring system. Fix the vulnerabilities based on their severity, choosing the most risky first. CWE also offers some great guidance on what it really means to prioritize; you can use CWE to help prioritize vulnerabilities that may affect your specific environment.
Additionally, leverage built-in features offered by the tools you’re using. For example, npm offers `npm audit` built into its CLI. Unfortunately, one of the complaints in the field is that more often than not, the false positives add an extra component of confusion and an extra layer of work. For more robust comprehensive protection and far fewer false positives, software composition analysis tools like FOSSA offer security scanning for your repositories, including every time you open a pull request.
Finally, it’s important to note that these are just a few of the methods recommended for prioritizing. Other factors include whether the vulnerable code is accessible during production, whether the exploit is known, the amount of damage that can be done by the exploit, and more. Take a look at the CVSS system to learn a bit more about leading factors that help determine the relative danger of any given vulnerability.
The XSS vulnerability can lead to massive damage. In January 2019, for example, an XSS vulnerability was disclosed in the Steam chat service, which could have led to millions of users being exposed to its dangers; another XSS vulnerability was also found in Steam in 2017, which could have affected their entire user base (over 120 million).
The core lesson here: Prioritize your vulnerabilities, and start by fixing those that are most common and easiest to access within your environment.
No less important than being aware of the most dangerous vulnerabilities is being aware of the most vulnerable packages. Putting these two factors together becomes a very powerful defense against attacks on your app.
Updating packages at will can be quite problematic and lead to major and expensive breaks in your build — which is why it may not always make sense to fix every vulnerability. Instead, combine what you know about the most dangerous vulnerabilities (to your app specifically) with the packages that you use to decide how and where to start fixing things and improving your security posture. Continue weighing pros and cons of risks when deciding. And document decisions you’ve made as you go so that you can track the policy you’ve curated for your organization specifically.
`lodash` and `jquery` are notoriously stricken with vulnerabilities. A quick search on NVD shows seven recent medium-, high-, and critical-severity vulnerabilities uncovered in lodash, and 13 for jquery in the last year alone. If you’re using those packages, you should stay on top of things and follow related alerts. It's worth understanding how these vulnerabilities affect your code health; also, it's important to stay on top of things here and fix affected components every time updates are offered. In fact, these are also two good examples of when it might be best to break a build to update or use alternative packages.
- Use maintained versions of well-known, common packages
- Fix the packages with the vulnerabilities most dangerous to your environment first
- Check packages before using to ensure they are well-maintained and up-to-date
- Be aware of your dependencies’ dependencies
- Align with your company policies for security and compliance