This blog post was the basis for the CHAOSScon North America talk. Watch the recording.
A Layered Approach to Open Source Security
Open source is everywhere now. More likely than not, your organization is using open source software (OSS), as it now makes up an estimated 96% of the total code base is now OSS. This is great news for development speed and innovation, but with this change comes added security risk. Alongside the rise of open source adoption, software supply chain attacks have also risen: In 2023, one survey found, 91% of organizations experienced a software supply chain attack. And that number keeps growing.
In the increasingly complex world of software supply chains, the walls organizations build to stave off threats tend to be porous. How else would so many attacks break through? And a single compromised dependency can have far-reaching and expensive consequences. There needs to be a more nuanced and resilient strategy. A strategy that acknowledges weaknesses within our current systems.
Enter the Swiss Cheese Model. Introduced by Professor James Reason in 1990, this model provides a powerful metaphor for understanding how failures occur in all sorts of complex systems. More importantly, it gives us an effective approach to building up defenses against those failures: layering security.
Imagine multiple slices of Swiss cheese stacked together. Each slice represents a different security layer. In an ideal world, any given defense would have no holes (no weaknesses). But that is not the world we live in. There are always areas of weakness. That’s why Reason uses Swiss cheese to demonstrate his point.
Holes in the Security System
In this cheese metaphor, a breach happens only when the holes in all the layers align, allowing a threat to pass through. The more layers you have, the less likely it is that this will happen. The smaller the holes are, the more likely that at least one layer of defense will keep your system safe.
In the context of open source security, these holes can manifest as:
- Active Failures: These are the unsafe acts committed by individuals in contact with the system. In software development, this could be a developer unknowingly introducing a vulnerability, committing a private API key, a system administrator misconfiguring a deployment, or a security team failing to apply a critical patch in a timely manner. Such failures have an immediate impact on the effectiveness of our defenses.
- Latent Conditions: These are the hidden weaknesses embedded within the system’s design, processes, or environment. Examples in the open source context include unmaintained dependencies, or maintainers for a dependency that are not able to keep up with pull requests and code review. These latent conditions can lie dormant, waiting for an active failure or malicious actor to trigger a security incident.
Reason wisely stated, “We cannot change the human condition, but we can change the conditions under which humans work.” The human condition comes hand in hand with human errors (active failures) and malicious actors. These are unavoidable. That’s why addressing latent conditions is crucial for long-term security. It’s also why layers of security–our metaphorical slices of cheese–are absolutely necessary.
Project Health Risk
One aspect of supply chain security that is too often overlooked is project health risk: or the latent risk that comes from dependencies that are not well maintained–or not maintained at all. Bitergia is an expert in project health metrics and analysis, and saw the need for an assessment that addresses project health risks at scale. Bitergia Radar uncovers the otherwise invisible activity within dependencies. This is one of the most proactive but underutilized layers to include in a Swiss Cheese Model strategy for OSS security.
The next section lays out some of the most important layers of supply chain security–including the project health risk assessment layer that Bitergia Radar provides. Each of these layers addresses different latent conditions. And they all work together to keep software supply chains secure.
Applying the Swiss Cheese Model to Open Source Supply Chain Security
So, how do we apply this model to build a more secure open source software supply chain? We need to implement multiple layers of defense that address the latent conditions–each layer designed to assess and manage security threats. The recent report commissioned by the UK, Open Source Software Best Practice and Supply Chain Risk Management, lays out recommendations for robust software supply chain security. These recommendations are layered, much like the Swiss Cheese Model.
Actively check and manage what’s going on with your dependencies with these “Swiss cheese” layers for increased supply chain security:
Generate an SBOM
SBOMs have become more and more popular for complex software supply chains. In part, new regulations on OSS have driven this popularity, but the UK study also cites this layer as one of its “best practices that constitute a proportionate and reasonable approach to OSS risk management.”
Definition: A Software Bill of Materials (SBOM) is a comprehensive and formally structured list of all software components, libraries, and dependencies used in a software product, including their version information, licenses, and upstream sources. It acts as a detailed inventory of your software’s building blocks, providing transparency into its complex composition.
Benefits of Generating an SBOM:
- Get a clear and comprehensive inventory of all of the open source components in your software.
- Have the necessary information to be able to identify and track potential security risks.
- Gain better understanding of licensing obligations and potential conflicts, setting yourself up to achieve compliance with emerging regulations and customer requirements for software transparency.
- Be more efficient with vulnerability management and incident response.
Holes in This Layer:
SBOM generation tools today do not produce reliable or complete results. They often leave gaps in our understanding of the software supply chain.
Another hole is that although an SBOM gives you essential visibility into complex software supply chains, it is merely information without analysis. It doesn’t in and of itself identify vulnerabilities or assess the sustainability or riskiness of projects. Rather, it is a first step. The following layers can use the SBOM to provide insights and enable action.
Apply Continuous Scanning of Vulnerabilities
The UK study also emphasized the importance of vulnerability scanning as a key line of defense for software supply chain security.
Definition: Continuous vulnerability scanning involves the ongoing monitoring of your software supply chain for known security vulnerabilities, licensing issues, and the availability of new versions for your open source components. This is often achieved with Software Composition Analysis (SCA) tools integrated into the Software Development Life Cycle (SDLC), particularly within the Continuous Integration/Continuous Deployment (CI/CD) pipeline.
Benefits of Continuous Scanning of Vulnerabilities:
- Proactively identify known vulnerabilities in your open source dependencies as soon as they are disclosed.
- Get a timely assessment of the potential impact of vulnerabilities on your applications.
- Be able to enact prompt mitigation efforts, such as patching or updating vulnerable components, reducing the window of opportunity for attackers.
- Have an automated process for vulnerability detection, reducing reliance on manual reviews.
- Better enforce organizational policies regarding acceptable OSS licenses and vulnerability thresholds.
Holes in This Layer:
Vulnerability scanning is inherently reactive. It identifies vulnerabilities that are already known or that conform to patterns that can be scanned for. It does not detect unknown vulnerabilities. Nor does it address the latent conditions–such as under-maintained or completely unmaintained dependencies–that allow for vulnerabilities to emerge in the first place.
Further, even as more and more organizations use vulnerability scanning, threats to open source keep rising. One 2020 study found “disclosed open source software vulnerabilities grew by 50% year-to-year–from just over 4,000 in 2018 to over 6,000 in 2019.” Other studies find that attacks are on the rise as well. The increasing volume of threats highlights the limitations of solely relying on scanning.
Vulnerability scans provide a vital but still partial picture. Another layer is needed to proactively assess risk.
Assess Project Health Risk
Although the UK study does not directly mention project health risk, it does lay out the need for using “metrics for evaluating the maturity and trustworthiness of OSS components.” OSS trust has been something that is difficult to achieve, but metrics for project health risk give early indicators of risk and help you to trust your dependencies.
The UK study goes on to point out that “the lack of a formal process for judging an open-source trustworthiness is an oversight.” They add that, “[t]his is particularly important given the increasing reliance on open-source software and the increasing number of vulnerabilities found in open-source software.” It’s true that most organizations have not yet embraced the importance of trust in their supply chains. But it is becoming increasingly critical that they do. Project health risk is now an essential layer to responsible OSS software security practice. In fact, another study found that “systems using outdated dependencies are four times as likely to have security issues as opposed to systems that are up-to-date.” This stark number highlights the urgency of understanding the maintenance activity of OSS dependencies, especially as attacks continue to rise.
And this is exactly what Bitergia Radar and a project health risk check does. It builds trust in the OSS components that make up software supply chains. By offering visibility, data, and analysis into maintenance activity, it allows for organizations to be proactive in investing in or abandoning risky dependencies, and to have trust in the ones they keep.
Definition: Assessing project health risk involves evaluating the sustainability and maintainability of dependencies. This layer to open source supply chain security is inherently proactive. In fact, it is one of the early lines of defense because it looks for weaknesses in the software supply chain before vulnerabilities are identified.
- A dependency is risky if it:
- Has a low level of maintainer activity, or is abandoned.
- Shows a decrease of maintainer activity over time.
- Is inefficient in addressing its issues and change requests.
An assessment of project health risk that Bitergia Radar provides goes beyond the common practice of scanning for known vulnerabilities. Rather, it delves into the early indicators of risk, including maintainer activity, community engagement, and responsiveness to issues. Metrics quantify these aspects and give insights into the project’s long-term riskiness or sustainability.
Benefits of Assessing Project Health Risk:
- Embrace a proactive approach to identifying potential security issues before vulnerabilities are even discovered.
- Build trust in your software supply chain by evaluating the maintenance activity and sustainability of dependencies.
- Comply with new regulations like the CRA that require “due diligence of manufacturers that integrate free and open-source software components.”
- Make informed decisions about adopting new dependencies or abandoning or investing in more risky ones.
- Complement your vulnerability scanning practices by getting ahead of risk.
Holes in This Layer:
While this layer is proactive and has only become more essential, it only looks at one aspect of open source software supply chains–the project health risk aspect. This layer should be part of a larger security approach that involves multiple layers.
One hole in this layer can be bad actors who create levels of activity in an open source project that appear healthy but are actually of malicious intent. This is what happened in the case of xzutils.
Another hole is that not all open source projects work the same way, and so, depending on the specific project, the meaning of metrics may change. The thresholds and models that Bitergia Radar builds may apply to a majority of projects, but they are not universally applicable. To reduce the size of these holes, we do not rely on fixed thresholds. Rather, we look for trends and relative comparisons.
There could be flawed information when assessing project health risk, which would be another hole. That’s why Bitergia Radar prioritizes high-quality data that can be relied on.
This layer can help focus our attention and turn the tools of other layers towards the potential holes that we have detected, thus moving the Swiss cheese slices to reduce the chance of an adverse effect.
Implement Internal Risk Mitigation and Management Policies
The UK study found that many organizations rely solely on developer discretion for open source adoption. That’s why they recommend establishing “an internal OSS policy to manage the adoption of components.” One that “balances risk with commercial advantages.” They must also “be willing to adapt their methods quickly.”
A Linux Foundation survey found that 69% of organizations with established OSS policies report significant improvements in managing the risk and security of their open source components.
Definition: An organization’s OSS risk mitigation and management policies and practices define the criteria for evaluating the trustworthiness and maturity of open source components. They also establish processes for their adoption, monitoring, and remediation. This includes guidelines for selecting secure and well-maintained dependencies, procedures for responding to identified vulnerabilities, and strategies for contributing back to the open source community.
Benefits of Internal Risk Mitigation and Management Policies:
- Ensure that decisions to adopt or abandon dependencies are not solely based on developer convenience. Rather, they are aligned with the organization’s security and risk tolerance.
- Provide a structured and repeatable process for managing OSS risk throughout the software lifecycle.
- Empower security teams to define acceptable risk levels and enforce consistent security controls.
- Facilitate confident decision-making about OSS adoption, response to problems as they arise, and investment in communities.
Holes in This Layer:
Without the data provided by the layers laid out above (SBOM, project health risk assessment, and vulnerability scanning), it is impossible to effectively implement a policy. The decisions to mitigate risk (e.g., adopt or abandon a dependency) need to be based on concrete information. It should not be up to developer discretion or whims, as the UK study points out is too often the case.
Furthermore, the effectiveness of these policies can still be undermined by human error (active failures). That’s why the other layers, such as project health risk assessment are necessary: the more the latent conditions are addressed, the less likely it is for active failures to occur.
The layers need to work in harmony, with data informing policy and policy guiding action. Rigid and unenforceable policies may lead developers to work around the policies, creating new and unknown holes in our defenses.
Conclusion: Building Resilience Through Layers and Vigilance
In the ever-evolving landscape of software development, open source software is no longer a peripheral element but the very foundation upon which most applications are built. The escalating threat of software supply chain attacks demands that we are more vigilant than ever. The Swiss Cheese Model provides a powerful and intuitive framework for understanding and addressing these risks. By implementing multiple, diverse layers of security, we can significantly reduce the likelihood of a single point of failure leading to a catastrophic breach.
Generating an SBOM provides essential visibility into our dependencies. Continuous vulnerability scanning acts as a crucial reactive layer, identifying and flagging known weaknesses. However, in today’s threat environment, relying solely on these measures is like patching holes after the damage is done. This is why the most proactive layer–project health risk assessment with tools like Bitergia Radar–becomes critical. By understanding the maintenance practices of the open source projects you depend on, you can identify weaknesses (latent conditions) before they manifest as threats. This added layer allows for informed decisions about risky dependencies and fosters trust in your software supply chain.
A robust OSS supply chain security strategy is not about erecting impenetrable walls, but about strategically layering defenses. It’s essential to understand the inherent weaknesses in each layer, and continuously monitoring the landscape. The time for a more multi-layered and proactive approach to OSS software supply chains is not coming–it is here.
Reach out or visit our website for more information about Bitergia Radar.
This blog post was written by Julia Lawson and Georg Link.
