Securing SDLC - Vulnerability in 3rd party components.

Every year the number of vulnerabilities reported in open source components increases. Unfortunately, software teams are often focusing only on functional requirements, and are unaware of security vulnerabilities in open source libraries. This behaviour might ultimately lead to a data breach, which could seriously impact the organization financially. The purpose of this article is to raise awareness of this problem, as well as present the solution.

There was a time when developers built their applications from scratch, but those days passed long ago. Nowadays, applications are more complex and increasingly rely on libraries and components created by 3rd parties. According to the Open Source Security and Risk Analysis (OSSRA) report presented by Black Duck in 2020 [1], 98% of proprietary applications contain around 75% of open source code - with an average of 528 open source components per application.

Let’s look at the numbers in more detail. The average Java library size is between 10k and 200k lines. According to research done by Aspect Security, typical custom Java applications contain somewhere between 5-10 security vulnerabilities per 10k lines of code. That gives between 5-200 vulnerabilities per library [2]. Now consider the number of open source libraries and components that are used by your application, and that should give you a worryingly large number of potential vulnerabilities.?

The more vulnerabilities there are in your code, the higher the probability that one of them will be exploited... Suppose a guy in a black leather coat offers you the chance to ignore all vulnerabilities, forever?

“This is your last chance. After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes.” [3]

Consequences of a breach

You can go with the blue pill and believe you are safe. What's the worst that can happen?.? A data breach? Just some private and personal data that you promised to keep safe and secure - and it is now available to anyone. Is that so bad?

For a start, you may need to pay a fine. In order to trade with other countries, the UK has passed laws based on the European General Data Protection Regulation (GDPR) which defines the maximum fine as up to ￡17.5 million or 4% of annual global turnover, whichever is greater [4]. And a fine is just the tip of the iceberg. According to a paper published by the FBI, after a breach, 60% of small and medium companies were out of business 6 months later [5]. Bigger companies also have problems. Equifax shares when it was breached went down by around 17% right after information about the breach became public [6].

Obviously, denial is not a good option.?

Consequences of mitigating the risks

You can take the red pill, address this issue and mitigate the risks. This time the first question that many people ask is: “How to start?”? The best place to start will be to review your project libraries. Look for libraries that are old and unmaintained. As a first check, just go to the library's source repositories, and check if they are being actively maintained - checking the date of the last update is a good starting point. If not, it is good practice to find a replacement library, because, if any security vulnerability is found and reported, then it is very likely that nobody will fix it. Ever. For maintained libraries, you need to check if there are any vulnerabilities reported. You can find this information in the release notes for the newer versions, or in reported issues. Then, as a further check, you can check in the National Vulnerability Database[7], which is a repository maintained by the US government that contains a list of all reported vulnerabilities.

This process may appear to be a bit tedious, but it can be automated with a Software Composition Analysis tool (SCA). There is a wide selection of SCA tools, with a wide variation in cost. Expensive tools might be a significant problem for small companies or startups, fortunately there are open source solutions, for example: OWASP Dependency Check.?

The same basic principle is behind all types of SCA tools. They scan the project codebase to identify Open Source libraries. They then check each library against a list of known vulnerable components. Most SCA tools use the National Vulnerability Database (NVD), which is maintained by the US government. Notably, some commercial tools use their own repository in addition to the NVD. This gives them some advantage, as there are a couple of days of delay between the moment when the vulnerability is announced to the public and the time when it will be added to the NVD. It is also wise to check against multiple vulnerability databases. There have been cases when a vulnerability has been published in the Chinese equivalent of NVD (CNNVD) several days before it was published in the NVD [8][9].

The report generated by the SCA tool contains a list of all of the software components and their vulnerabilities. Each vulnerability that has been found? is scored in a range from 0-10, where a higher value means risk is higher. The scoring standard that is used to score components is called the Common Vulnerability Scoring System (CVSS) and it is an open standard [10]. The CVSS score considers things like attack vector, complexity and scope, and for each component, the score reflects the sub-component that poses the highest risk. So, just one vulnerable component can result in a very poor CVSS score.

This is the time for developers to act, and migrate the codebase to the latest non-vulnerable version of libraries. Rapid response is vital when a vulnerability has been found. For example: In 2017 the American consumer credit reporting agency was hacked [6]. The attackers used a vulnerability in Apache Struts to steal over 150 million customer records. Now the vulnerability was reported in March, but the breach happened 2 months later in May. What was happening during those two months? Three days after the information about the breach was publicly known, security researchers discovered unknown hackers probing various websites looking for potential targets - ones where the vulnerability had not been fixed. This shows how important a quick response is when a serious vulnerability is discovered in one of the components of your system.?

The share of Open Source code in proprietary applications is increasing over the time, and keeps growing. In general this is a good trend, as developers don't need to continually reinvent the wheel, but there can be problems. Open Source components lack liability, which means you are using it at your own risk. As much as this doesn’t sound encouraging, many people involved in building and securing applications forget about this. It is important to remember, because if your codebase contains abandoned libraries, then you will need to fix all the security issues that arise - by yourself.?

As mentioned before, SCA tools do not scan components, they just cross check them against vulnerability database(s). Which means that a library that looks safe, might contain vulnerabilities that haven’t been discovered and reported yet. To increase the safety of your application, some security professionals suggest carrying out a full security assessment of each library, and use only versions that pass them. Using fully tested and approved libraries will definitely improve applications security.?

In 2017 security researchers from Snyk analysed 25 biggest breaches and discovered that around 25% of them were caused by vulnerabilities in open source components [11]. You might say now “So the 75% of code in open source libs is the least vulnerable bit”, and you will be right. Just remember, we are talking about open source libraries that are often reviewed by many parties, while the other 25% of the code is only known by your team members. Those team members might not necessarily receive proper security awareness training or/and work under pressure to complete their tasks (we have all been there). Remember that the more vulnerabilities there are in your code, the higher the probability that one of them will be exploited… Feeling lucky? Roll those dice! Ooops: a six! That’s a breach, which means the company is likely to fail and everyone will lose their job.?

This shows that introducing SCA tools as part of the development process could provide significant improvements to the application security, and helps to flag components with vulnerabilities that might have a severe impact on the application security. With a tightening time gap between the time when a vulnerability is publicly announced, and the time when hackers are able to exploit it, being reactive might not be enough. Developers need to be more proactive. This means that updating libraries to the latest version should be a regular exercise, not a one time thing.

Conclusion

To summarize it, each organisation, no matter how big or small it is, should think about a data breach as a very real possibility. It doesn’t just happen to other companies! A breach might cause severe damage to the company, and a high percentage of all breaches are caused by a known vulnerability in one of the components. Do companies employ developers who produce code that they know will fail? Scanning components for known vulnerabilities is a good starting point for building applications that are more secure.

References:?

[1]? Open Source Security and Risk Analysis Report 2021 - Black Duck

[2] https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/contrast_-_insecure_libraries_2014.pdf

[3] The Wachowskis (Directors), The Matrix [film], Warner Bros

[4] Data Protection Act 2018

[5] Testimony of Dr. Jane LeClair, Chief Operating Officer, National Cybersecurity Institute at Excelsior College, before the U.S. House of Representatives Committee on Small Business (Apr. 22, 2015), available at https://docs.house.gov/meetings/SM/SM00/20150422/103276/HHRG-114-SM00-20150422-SD003-U4.pdf.

[6] https://en.wikipedia.org/wiki/2017_Equifax_data_breach

[7] https://www.nist.gov/programs-projects/national-vulnerability-database-nvd

[8] https://www.cnnvd.org.cn/

[9] https://www.recordedfuture.com/chinese-vulnerability-reporting/

[10] https://www.first.org/cvss/v3-1/cvss-v31-specification_r1.pdf

[11] https://snyk.io/blog/owasp-top-10-breaches/