Open-source Library – Open software or Open vulnerabilities

The recent LOG4j vulnerability stormed the information technology industry out of the blue with a vulnerability CVSS score of 10. However, it seemed like a simple logger issue in the beginning; within no time, the severity of LOG4j vulnerability was estimated to be potentially one of the most severe computer vulnerabilities in years. The vulnerability was described as a “design failure of catastrophic proportions” by Mr. Free Wortley, CEO, Lunasec. The UK National Cyber Security Center (NCSC) stated that remediating LOG4j can take weeks or months based on the size of the organization. They also predicted that the cybersecurity teams can suffer burnout in this process. The challenge in patching these vulnerabilities is that many organizations run older versions of Java, and critically, if things go wrong in the process of patching, it can compromise the logging capability of an organization, which is needed to identify any attempt to exploit this vulnerability. The Log4j vulnerability is an ideal example of how adversely a single flaw in the foundational piece of code used extensively in software can impact the industry. This entire adverse situation has raised a lot of concerns about the concept of open source. This work attempts to throw light on the advantages and concerns of open source.

OSS if properly implemented can be an asset. If not, in addition to its diminishing reliability, can turn into a workplace liability, an accident waiting to happen.

Open-source refers to libraries/software with publicly accessible source code that can be seen, modified, and distributed by anyone. The philosophy behind open-source libraries/software is that public access to source code can make them powerful and reliable. The OSSRA 2021 report estimated that 99% of the audited codebases contain open-source components, which is a rise by 259% in the last five years. It is widely believed that open-source complements developers during agile application development by saving time and cost. Also, the code of open-source software (OSS) is considered more secure and stable, as it is continuously accessed, assessed, and refined by a large community of experts.

Despite these advantages, there are significant concerns that developers and organizations encounter as a result of implementing the open-source. OSS rarely comes with long-term, high-quality technical support, and warranty (like Microsoft, Oracle, etc.). Though OSS is initially cost-effective, in the long run, expenses escalate due to software maintenance and updates. The high demand for skilled Linux workers also contributes to the rise in costs and forces companies to explore and adopt new measures in order to implement and maintain OSS. The processes of software development in open source are majorly community-oriented undertakings, which may not guarantee the reliability of the open software at all times. Open-source components are not created equal; most of the projects are developed and maintained by few contributors, which most of the time results in burnout. The difference in the skills, knowledge, time spent on a project, and experience of the contributors also affect the quality and reliability of OSS.

Finally, by virtue of its underlying philosophy, OSS introduces serious cybersecurity concerns that can adversely impact an entire organization’s platform and data security. The nature of the open-source model places the source code and the complete details of the vulnerabilities present in it for public scrutiny. This facilitates hackers with the required information to carry out a cyberattack. Also, the OSS model can accommodate an attacker to impersonate as a project contributor and distributor of projects containing malicious code. The OSSRA report 2021 states that the growth in open source contributes to the increase in open-source vulnerabilities that can critically impact the security and stability of applications that implement OSS. The report also stated that more than 75% of audited codebases possessed components with publicly known security vulnerabilities. Some OSS possess vulnerable components from the start, while others go bad over time. The primary challenge for organizations is to detect and keep track of the security risks posed by the open-source libraries. Most of the time, organizations aren’t aware of the exposed security vulnerabilities in one of their components. Even if they are aware, they may respond slowly in patching their OSS. This issue is further compounded due to disparity in the features and architecture of different versions of the same OSS. All these factors cumulatively give an attacker the time and strategy to launch an attack and breach the data of an organization. Sometimes, the vulnerabilities in an OSS might have a feature that is vulnerable but may not get exposed publicly until someday someone makes it public.

Security risks occur even in proprietary software, but the scenario is too complex in OSS. The Sonatype 2021 report stated that supply chain attacks against OSS increased by 650% in 2020. Hackers are more interested in finding vulnerabilities in OSS, as the source code is publicly accessible. Unlike its contemporaries, when there is a vulnerability or a cyber-attack caused by OSS, questions such as How long did the vulnerability exist? Did the developers/contributors know it earlier? Were attackers already secretly exploiting it? Will it remain unanswered, maybe forever? Mitigating and resolving issues in OSS is a complicated process. For example, in the LOG4j issue, before organizations could patch their products with the latest version 2.15.0, a vulnerability was identified in 2.15.0, for which 2.16.0 was released. Before organizations could update further, there was a vulnerability in 2.16.0, also for which 2.17.0 was released. No one knows how long this loop will continue, but we just hope it’s not an infinite one. Having said all that, OSS implemented with proper understanding and governance policies when monitored, tested, and updated continuously can be a great asset for an organization. If not, open-source, in addition to its diminishing reliability, can turn into a workplace liability, an accident waiting to happen.

References:

1. Newman, Lily Hay. “‘The Internet Is on Fire.’” Wired. www.wired.com, https://www.wired.com/story/log4j-flaw-hacking-internet/. Accessed 22 Dec. 2021.
2. Log4j Vulnerability: What Should Boards Be Asking? https://www.ncsc.gov.uk/blog-post/log4j-vulnerability-what-should-boards-be-asking. Accessed 22 Dec. 2021.
3. “Open-source Libraries & Security Vulnerabilities - SaaS.” Quality Clouds, 19 May 2021, https://www.qualityclouds.com/open-source-libraries-and-security-vulnerabilities/. Accessed 17 Dec. 2021.
4. What Is Open-source Security? | Micro Focus. https://www.microfocus.com/en-us/what-is/open-source-security. Accessed. 17 Dec. 2021.
5. Why Open-source Misses the Point of Free Software - GNU Project - Free Software Foundation. https://www.gnu.org/philosophy/open-source-misses-the-point.en.html. Accessed 17 Dec. 2021.
6. 2021 Open-source Security and Analysis Report | Synopsys.https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html. Accessed 20 Dec. 2021
7. “3 Strategies for Better Open-source Support.” The New Stack, 2 Oct. 2019, https://thenewstack.io/how-to-address-the-problem-of-open-source-software-support/. Accessed 20 Dec. 2021
8. Zhao, Wenjia. “Beliefs And Misbeliefs About Open-source Software.” Forbes, https://www.forbes.com/sites/wenjiazhao/2012/07/06/beliefs-and-misbeliefs-on-open-source-software/. Accessed 20 Dec. 2021.
9. 5 Risks of Open-source Software | Snyk. 29 June 2021,https://snyk.io/learn/risks-of-open-source-software/. Accessed 20 Dec. 2021.
10. “Security Risks of Open-source Software.” Analytics India Magazine, 12 July 2021, https://analyticsindiamag.com/security-risks-of-open-source-software/. Accessed 20 Dec. 2021.
11. Shallom, Dan. “DLL Injection Attack in Kerberos NPM Package.” Medium, 17 May 2020, https://medium.com/@kiddo_Ha3ker/dll-injection-attack-in-kerberos-npm-package-cb4b32031cd. Accessed 20 Dec. 2021.
12. Inc, Sonatype. The 2021 State of the Software Supply Chain Report | Download. https://www.sonatype.com/resources/white-paper-2021-state-of-the-software-supply-chain-report-2021. Accessed 23 Dec. 2021.