Published by gbaf mag
Posted on October 22, 2020
6 min readLast updated: January 21, 2026
By Emile Monette, Director of Value Chain Security at Synopsys
Software Supply Chain Security: change is needed
Attacks on the Software Supply Chain (SSC) have increased exponentially, fueled at least in part by the widespread adoption of open source software, as well as organisations’ insufficient knowledge of their software content and resultant limited ability to conduct robust risk management. As a result, the SSC remains an inviting target for would-be attackers. It has become clear that changes in how we collectively secure our supply chains are required to raise the cost, and lower the impact, of attacks on the SSC.
A report by Atlantic Council found that “115 instances, going back a decade, of publicly reported attacks on the SSC or disclosure of high-impact vulnerabilities likely to be exploited” in cyber-attacks were implemented by affecting aspects of the SSC. The report highlights a number of alarming trends in the security of the SSC, including a rise in the hijacking of software updates, attacks by state actors, and open source compromises.
This article explores the use of open source software – a primary foundation of almost all modern software – due to its growing prominence, and more importantly, its associated security risks. Poorly managed open source software exposes the user to a number of security risks as it provides affordable vectors to potential attackers allowing them to launch attacks on a variety of entities—including governments, multinational corporations, and even the small to medium-sized companies that comprise the global technology supply chain, individual consumers, and every other user of technology.
The risks of open source software for supply chain security
The 2020 Open Source Security and Risk Analysis (OSSRA) report states that “If your organisation builds or simply uses software, you can assume that software will contain open source. Whether you are a member of an IT, development, operations, or security team, if you don’t have policies in place for identifying and patching known issues with the open source components you’re using, you’re not doing your job.”
Open source code now creates the basic infrastructure of most commercial software which supports enterprise systems and networks, thus providing the foundation of almost every software application used across all industries worldwide. Therefore, the need to identify, track and manage open source code components and libraries has risen tremendously.
License identification, patching vulnerabilities and introducing policies addressing outdated open source packages are now all crucial for responsible open source use. However, the use of open source software itself is not the issue. Because many software engineers ‘reuse’ code components when they are creating software (this is in fact a widely acknowledged best practice for software engineering), the risk of those components becoming out of date has grown. It is the use of unpatched and otherwise poorly managed open source software that is really what is putting organizations at risk.
Emile Monette
The 2020 OSSRA report also reveals a variety of worrying statistics regarding SSC security. For example, according to the report, it takes organisations an unacceptably long time to mitigate known vulnerabilities, with 2020 being the first year that the Heartbleed vulnerability was not found in any commercial software analyzed for the OSSRA report. This is six years after the first public disclosure of Heartbleed – plenty of time for even the least sophisticated attackers to take advantage of the known and publicly reported vulnerability.
The report also found that 91% of the investigated codebases contained components that were over four years out of date or had no developments made in the last two years, putting these components at a higher risk of vulnerabilities. Additionally, vulnerabilities found in the audited codebases had an average age of almost 4 ½ years, with 19% of vulnerabilities being over 10 years old, and the oldest vulnerability being a whopping 22 years old. Therefore, it is clear that open source users are not adequately defending themselves against open source enabled cyberattacks. This is especially concerning as 99% of the codebases analyzed in the OSSRA report contained open source software, with 75% of these containing at least one vulnerability, and 49% containing high-risk vulnerabilities.
Mitigating open source security risks
In order to mitigate security risks when using open source components, one must know what software you’re using, and which exploits impact its vulnerabilities. One way to do this is to obtain a comprehensive bill of materials from your suppliers (also known as a “build list” or a “software bill of materials” or “SBOM”). Ideally, the SBOM should contain all the open source components, as well as the versions used, the download locations for all projects and dependencies, the libraries which the code calls to, and the libraries that those dependencies link to.
Creating and communicating policies
Modern applications contain an abundance of open source components with possible security, code quality and licensing issues. Over time, even the best of these open source components will age (and newly discovered vulnerabilities will be identified in the codebase), which will result in them at best losing intended functionality, and at worst exposing the user to cyber exploitation.
Organizations should ensure their policies address updating, licensing, vulnerability management and other risks that the use of open source can create. Clear policies outlining introduction and documentation of new open source components can improve the control of what enters the codebase and that it complies with the policies.
Prioritizing open source security efforts
Organisations should prioritise open source vulnerability mitigation efforts in relation to CVSS (Common Vulnerability Scoring System) scores and CWE (Common Weakness Enumeration) information, along with information about the availability of exploits, paying careful attention to the full life cycle of the open source component, instead of only focusing on what happens on “day zero.” Patch priorities should also be in-line with the business importance of the asset patched, the risk of exploitation and the criticality of the asset. Similarly, organizations must consider using sources outside of the CVSS and CWE information, many of which provide early notification of vulnerabilities, and in particular, choosing one that delivers technical details, upgrade and patch guidance, as well as security insights. Lastly, it is important for organisations to monitor for new threats for the entire time their applications remain in service.
Explore more articles in the Top Stories category
