Leveraging Open Source and Mitigating the Associated Risks
By NaimishaPublished On March 24, 2021
Incremental usage of open source libraries and licenses
With an ever-increasing reliance on the software development teams and the shift towards DevOps – developers are asked to push more production-ready code daily. To have an efficient release workflow and continuous push, developers bank on an open source ecosystem with libraries or pre-built functional code, which transcends their efforts without having to build such functions from scratch. As a result, with an optimal contribution from developer tools, open source code, and 3rd party developers, the reality is – the control over what is in your code has changed with time.
Open source plays a critical role in today’s software ecosystem and has become the backbone for modern applications. Synopsis OSSRAreport says that across all codebases audited in 2020, every codebase had at least one open source component. These open source components comprise 40-60% of the overall code.
Why open source libraries/software pose a security threat
As the usage of open source libraries across the software ecosystem is proliferating, so are the potential risks to an organization. Additionally, one of the most interesting trends identified in 2020 which is at the same time concerning was that of the incrementing security risk modeled by unmanaged open source components. As per the survey by Synopsis, it was recognized that approximately 75% of the codebases reviewed had known vulnerabilities identified with open source components.
While organizations are embracing the software ecosystem with open source components, it is important to consider that, with the use of reusable snippets of code and associated functionality also comes the potential of adversaries reusing the vulnerabilities once identified in those snippets of code. Once the vulnerability is identified in an open source component; it can have a cascading effect on an organization, making hundreds of applications vulnerable using the same exploit.
Besides, organizations lack in today’s date is the ability to track dependencies related to open source components in an application code. If the organizations don’t have 360-degree visibility to their underlying application package (especially the tree of open source dependencies), it would be nearly unmanageable for them to identify and remediate a vulnerability identified in an open source component.
The major threats for an organization using open source code include:
Vulnerabilities across deployed open source components/libraries
Malicious libraries impacting the application or supply chain
Few known security occurrences, wherein an attacker was successful using tactics mentioned above, includes:
In the quite notorious use case of Equifax Breach, adversaries had exploited a vulnerability in the Apache Struts2 open source component. This enabled the attackers to compromise and exfiltrate personally identifiable information of approx. 148 million people. In this case, Equifax had failed to identify and patch the vulnerable open source component in their web applications.
In another use case for open source web content management framework, Drupal – a major remote code execution vulnerability was identified called Drupalgeddon in which the vulnerability potentially allowed adversaries to target Drupal sites with multiple attack vectors, which could result in the site being compromised.
Thus, with an incredible growth trend of using open source components across the software development lifecycle, organizations must realize that:
The use of open source components does reduce the development time and efforts, but it has its share of shortcomings
Open source components provide an unwilling advantage to adversaries to conduct reconnaissance and identify any open vulnerabilities which could be leveraged to exploit the applications
Identifying the challenges and solution
Organizations today have to understand how the open source ecosystem looks like for them. To have absolute transparency, they should attempt to answer the following questions –
Which open source libraries are being leveraged in their software built across the organization? Are there any vulnerabilities associated with them?
If they have any identified vulnerabilities across their open source ecosystem, what does the vulnerable library do? What is its potential impact on the software or customers? Does the library perform any malicious activity?
How can they react fast enough to new vulnerabilities in the identified open source dependencies or libraries?
There are multiple means for an organization to get started on their journey to secure the open source ecosystem based on their needs, priorities, and maturity of the program. We have listed some of the ‘must haves’ to consider:
1.Open Source Inventory – Without a current state understanding of the open source ecosystem for your organization, it is challenging to address potential issues arising from it. Organizations should prioritize creating an inventory of all the open source components used within their software/tools with details such as versions in use, project locations, dependencies (the code is calling or libraries link to the open source), licensing, etc.
Creating a process around inventoried components reduces the thrust of a potential attack. It is highly recommended to create policies to ensure automated processes that can help track the open source components, their licenses, and known security vulnerabilities.
2.Continuous Monitoring – Given the reliance on continuous releases and applications push to keep operations running, security in the development and deployment process cannot be an afterthought. It is essential to continuously monitor the open source tools and components used such as the open source container community.
Most popular images are often built considering a broad set of use cases and thus, there is a better probability to also have multiple vulnerabilities. Software Composition Analysis (SCA) can be leveraged to discover, identify and integrate with processes with CI/CD or DevSecOps pipeline to remediate vulnerabilities including exposing licenses for open source components.