Using Components with Known Vulnerabilities

Most applications make use of large amounts of third-party components. These components provide everything from logging, templating, database access, and more. 

This makes developing software much easier, saving a lot of time, however, these components are also made by people and some will inevitably contain vulnerabilities. This means you might be unknowingly exposed to vulnerabilities that could be exploited.

Keeping components up to date

As a general rule of thumb, it's strongly recommended to keep frameworks, libraries, and other components up to date on a regular basis. This can be done in a number of ways:

• A lot of source control software can analyze your repositories and alert you when a vulnerability has been found in a dependency
• Many package managers can analyze your application and identify any vulnerable dependencies you may have
• Numerous Software Composition Analysis (SCA) solutions exist out there which can identify any vulnerable dependencies 

Mitigating the risk of technical debt

One rather insidious problem with upgrading libraries is that they can have code-breaking changes. While these are often documented, there can also be undocumented changes that may not appear until your code is running in production. 

If your application is running many versions behind the most current one, there may be a significant amount of work needed to upgrade to the latest version. In the case where a time-sensitive vulnerability is disclosed, it's critical that you’re relatively up-to-date with third-party components to avoid a situation where the upgrade will take days to do. 

It’s also not recommended to blindly upgrade packages without at least reading release notes as they may contain important information about changes that are not obvious but could change the way your application functions. 

Could updating make you more insecure?

While it’s not common, there have been instances where a vulnerability may:

• Not exist in older versions
• Be introduced when fixing a vulnerability

These cases may lead one to believe that updating packages on a regular basis isn’t really desirable. Of course, this thinking should be avoided where possible as it leads to the build-up of technical debt. 

Given the relative rarity that this scenario represents, the benefits of frequently updating packages far outweigh the possibility of a newly introduced vulnerability, which should be easily mitigated anyway if you’re staying up to date on a regular basis. 

It also makes the assumption that vendors don’t silently fix vulnerabilities without any disclosure, which is unfortunately still very common. 

Notable examples

A few notable examples you will likely have heard of in recent times are listed below. You can see how and why it’s important to check your libraries and ensure you’re staying up to date. 

• Heartbleed
• Struts2
• Log4j

‍