Using Components with Known Vulnerabilities

When dealing with cyber vulnerabilities, there are lots of threats that are unknown and ever changing that can put users at risk.  We often hear about the latest zero-day to wreak havoc with its clever name. But not all threats come from unexpected sources. Many originate through ancillary software dependencies with known issues that are overlooked, accepted as a risk, or not properly maintained. These may be simple library dependencies, or a full-bore application such as an embedded web server, or something in between. Using components with known vulnerabilities has been the cause of some of the most significant breaches to date, and it’s long-term status on the  OWASP top 10 list reflects this.

Often times, cyber criminals are enticed by these flaws due to their relative ease of discovery through automated scanning tools, or even by the use of manual analysis techniques. Being known issues, they can rapidly determine what kind of impact they can have with their attacks, which allows them to assess the potential risk vs reward quickly. And since this is a vulnerability that is so open-ended, it can often range in weaknesses to include injection, broken access control, and XSS. It also can range from a minimal impact or complete host takeover and data compromise.

Vulnerable components can be widespread within organizations, and often can be caused by simply not maintaining a complete software component inventory including the origin and versions for each active component. This can lead to running out of date and unpatched software designed to fix any previous flaws. Often times, the components themselves are not even the real problem, sometimes it is the subcomponents that are vulnerable. It is not uncommon for one dependency to require several others, each of which may require others, and so on.  Libraries (and libraries that they rely on) commonly can contain these vulnerabilities and known issues. These subcomponents can often be heavily relied upon, and attacking them can cause a chain reaction for a greater effect to the main component. 

To combat the use of components with known vulnerabilities, the easy answer is to say not to use any components that were not written and maintained internally, but this is not realistic for most organizations. In reality, the best thing is to have security procedures in place to include keeping a well-maintained inventory of all versions of current components and regular testing of the components to check for any updates and security patches. Part of this regular maintenance should also include identifying and removing any unneeded and unused items as well as monitoring for components that do not create security patches or updates. When seeking new components, updates, and patches, try to obtain them from official or trusted sources over secure links. Commonly, security patches are not made for older versions of open source software. Instead, they will simply fix any known issues with a newer version. So always make sure that the latest versions of these components are being used.

When identifying the known issues, as mentioned earlier, attackers often use automated tools as well as manual analysis techniques. Companies should also take this approach for detection as part of their maintenance and ensure that not only components but also subcomponents such as libraries (and libraries that they rely on) are not vulnerable. This may seem tedious, but it can also be done internally with the use of many different options of security scanners as well as externally with the use of specialized services that can assist with the process.

The key here is good documentation of current versions and regular maintenance of all components and subcomponents. These should be scanned, updated, and patched regularly, and there should be a plan in place to continue efforts to keep them safe from known vulnerabilities.