Organizations must manage known vulnerabilities in web applications. When it comes to application security, the Open Web Application Security Project (OWASP) Foundation Top 10 is the primary source to start reviewing and testing applications.

The OWASP Foundation list brings some important questions to mind: Which vulnerability in the OWASP Foundation Top 10 has been the root of most security breaches? Which vulnerability among the OWASP Foundation Top 10 has the highest likelihood of being exploited?

While “known vulnerable components” comes in at number nine on the list, it’s the weakness that is most often exploited, according to security firm Snyk. The OWASP Foundation stressed on its website, however, that the issue was still widespread and prevalent: “Depending on the assets you are protecting, perhaps this risk should be at the top of the list.”

So, how can these known vulnerabilities be managed?

Vulnerable Components Can Lead to Breaches

Components in this context are libraries that provide the framework and other functionality in an application. Many cyberattacks and breaches are because of vulnerable components, a trend that will likely continue, according to Infosecurity Magazine.

Recent examples include the following:

• Panama Papers: The Panama Papers breach was one of the largest-ever breaches in terms of volume of information leaked. The root cause was an older version of Drupal, a popular web server software, as noted by Forbes.
• Equifax: The Equifax breach was one of the most severe data breaches because of the amount of highly sensitive data it leaked, as noted by Forbes. The root cause was an older version of Apache Struts.

Often, this vulnerability is not given the attention it requires. Many organizations may not even have a proper inventory of dependent libraries. Static code analysis or vulnerability scans usually don’t report components with known vulnerabilities. In many cases, the component versions would have reached their “end of life,” but were still in use.

It’s also worth considering the complexity of managing component licenses. There are many open source licenses with varying terms and conditions. Some licenses are permissive and some are permissive with conditions (strong or weak copyleft). The Open Source Initiative (OSI) lists more than 80 approved licenses.

Most Components Are Older Versions With Known Vulnerabilities

Synopsys reported that more than 60 percent of libraries being used are older versions that have known vulnerabilities. If we take a deep look at our applications component profile, this may not be an exaggeration. Most of the web applications running today are using open source components in some way or another.

The popular open source frameworks for web applications include:

• Struts
• Spring MVC
• Spring Boot
• MyFaces
• Hibernate in Java
• Angular
• Node.js in JavaScript
• CSLA framework in .NET
• Many PHP, Python and Ruby frameworks

There are also many object-relational mapping components, reporting tools, message broker components and a plethora of other utility components to consider. These components provide great advantages to organizations concerning cost-benefit, being future ready and helping foster digital transformation. They also have a wide developer base to develop and maintain components actively.

But are you using an older version of these components? Do they have reported vulnerabilities? Common Vulnerabilities and Exposures (CVE) in components are listed in CVE MITRE and National Vulnerability Database (NVD).

More Than 80 Types of Various Open Source Licenses

Managing open source licenses is an important activity for an organization’s open source strategy and legal and standard compliance programs. Managing licenses for components can be complex. Due care must be given to note the license version, as some may have significantly different terms and conditions from one version to another. Developers may add open source libraries to applications without giving much thought about licenses.

The perception is that open source is “free.” However, the fact is it’s “free” with conditions attached to its usage.

If we review the license clauses carefully, the requirements are more stringent when it comes to distributed software. Reviewing the license requirements of a component will also include reviewing the licenses of transitive dependencies or pedigrees — the components on which it is built. Open source compliance programs usually cover software installed on machines but may not cover the libraries used by web applications.

Automate to Identify Components With Known Vulnerability and License Risks

NVD uses Common Platform Enumeration (CPE) as the structured naming scheme for information technology (IT) systems, software and packages. The tools that automate the process get the CPE dictionary and CVE feed from NVD. The feeds are available in JSON or XML formats. The tools parse the feeds and scan through them with the CPE to provide reports.

The OWASP provides Dependency-Check, which identifies reported vulnerabilities in project dependencies. It’s easy to use and can be used in command line or integrated into the build process. It has plug-ins for popular build management tools, including Maven, Ant, Gradle and Jenkins. The build tool Maven has a “site” plug-in. By running “mvn site” command it produces the application specific report, which also shows the license information on dependencies.

There are many other commercial tools with more sophisticated functionality — beyond vulnerability identification and listing licenses. There are sources other than NVD and CVE MITRE, which provide details on known bugs, such as RubySec, Node Security Platform and many bug tracking systems.

Addressing Component Issues: Upgrade, Replace or Migrate

The most important step in managing open source licenses is to have a policy on acceptable licenses. The policy has to be created in consultation with your legal department. The policy should be reviewed periodically and kept up-to-date. Building an inventory of components is also important.

Once the components are identified as being vulnerable or not, and that they comply with license policy, addressing them is context specific. You can either upgrade to the latest version or replace them with alternates. This requires a risk-based approach and planning. Framework upgrades — or moving to a different framework or technology — could result in significant development efforts. The approach has to be decided based on risk and cost, considering all alternate deployment models and technologies.

Upgrading components or migrating can be rewarding. In addition to addressing security issues, it can provide an opportunity to improve the performance of the applications and address compatibility issues because of older component versions.

Component management is a continuous process, as vulnerabilities get frequently reported — even in the latest of versions. Obviously, it’s not practical to upgrade or migrate each time an issue is reported — often patches (minor versions upgrades) will be available to address the issues. Component management should be given adequate consideration and must be an integral part of an organization’s application security and compliance programs.