The Role of SBOMs and OSPOs in Securing Open Source Software

Introduction

In today’s software ecosystem, where open-source components are the backbone of modern development, ensuring transparency and security is essential. Organizations often depend on dozens, if not hundreds, of open-source libraries and dependencies, which bring both flexibility and risk. Without visibility into these components, managing security vulnerabilities, legal compliance, and supply chain risks becomes challenging. This is where the Software Bill of Materials (SBOM) steps in.

An SBOM provides a detailed, machine-readable inventory of all software components—whether they’re open-source libraries, proprietary code, or third-party tools. By offering this clarity, SBOMs help organizations track licenses, vulnerabilities, and risks associated with each component, allowing for better management of software dependencies.

As the adoption of open-source software grows, SBOMs are becoming crucial for protecting organizations from security breaches, supply chain vulnerabilities, and compliance violations. They offer transparency into software components, helping organizations proactively manage risks associated with third-party and open-source libraries.

For organizations with Open Source Program Offices (OSPOs), integrating SBOM practices is vital for ensuring the responsible and secure use of open-source software. OSPOs play a key role in governance, compliance, and aligning with emerging regulatory requirements.

In this article, we will explore the importance of SBOMs, review open-source tools for generating and managing SBOMs, address the challenges of SBOM adoption, examine the role of OSPOs, discuss emerging global SBOM requirements in the U.S. and the EU, and provide a look at the future of SBOM as a critical element of software security.

What is an SBOM?

At its core, an SBOM (Software Bill of Materials) is a comprehensive list of all the components, libraries, and dependencies that make up a software application. It includes important details like the component’s version, license, and source. This is particularly crucial in open-source environments, where software often relies on third-party libraries. With an SBOM, developers, security teams, and legal departments can better understand the software’s composition, helping them identify security vulnerabilities, resolve licensing conflicts, or manage outdated components.

Think of an SBOM like the ingredient list on a packaged food product. Just as a food label tells you what ingredients are included, where they come from, and whether any allergens are present, an SBOM shows all the components inside a software application, their origin, and any potential risks, such as outdated or vulnerable dependencies. This transparency is essential for maintaining security and ensuring legal compliance.

Open-source software is particularly susceptible to supply chain attacks, where malicious actors target third-party libraries. An SBOM provides a record of all components, so when a vulnerability is discovered, it can be identified and addressed quickly. It’s similar to how a contaminated ingredient in a food supply chain can be traced, recalled, and replaced to ensure safety.

Open Source Tools for SBOM Generation

In the growing need for security and compliance in open-source software, several tools are available to automate the creation and management of Software Bill of Materials (SBOMs). These tools not only generate SBOMs but also monitor dependencies, ensuring that any vulnerabilities are quickly identified and mitigated.

Syft

Syft is an open-source tool designed to scan source code, container images, and filesystems to generate SBOMs in formats such as SPDX and CycloneDX. It is particularly useful in containerized environments, where managing dependencies across multiple layers can be complex. Syft integrates seamlessly into the DevOps pipeline, allowing SBOM generation to occur automatically as part of the build process.

For instance, when vulnerabilities like Log4j are discovered, Syft enables quick identification of which containers or codebases contain the vulnerable version of the library. This allows development and security teams to respond swiftly and efficiently. Syft’s focus on automating SBOM generation makes it essential for environments where updates and deployments happen frequently.

CycloneDX-CLI

The CycloneDX-CLI is a powerful command-line tool specifically designed to generate SBOMs in the CycloneDX format, which emphasizes security and risk management. The CycloneDX format not only catalogs dependencies but also maps them against known vulnerabilities, making it an essential part of security-focused development environments. The CLI tool integrates directly with CI/CD pipelines, ensuring that every build is accompanied by an updated SBOM.

CycloneDX’s security focus makes it particularly relevant for sectors like healthcare and finance, where compliance and risk mitigation are critical. By continuously updating SBOMs during the build process, CycloneDX ensures that even small changes in dependencies are tracked, helping organizations manage potential vulnerabilities more effectively.

Dependency-Track

Dependency-Track takes SBOM management a step further by continuously monitoring for vulnerabilities. While it doesn’t generate SBOMs itself, it ingests SBOMs from other tools like Syft or CycloneDX and provides ongoing security analysis. By cross-referencing software components with databases such as the National Vulnerability Database (NVD) and OSS Index, Dependency-Track alerts teams when new vulnerabilities are discovered in existing components.

This real-time monitoring is crucial for environments where software is deployed for extended periods, ensuring that long-term risks are managed effectively. For example, if a vulnerability is newly discovered in an open-source library used in software deployed months or years ago, Dependency-Track will flag it, allowing teams to act before it becomes an exploited security hole.

OSV-Scanner

The OSV-Scanner is another powerful tool that integrates deeply into the SBOM ecosystem by directly addressing security vulnerabilities in open-source software. It uses Google’s Open Source Vulnerability (OSV) database, a comprehensive repository of vulnerabilities affecting open-source projects, to identify potential risks. OSV-Scanner is designed to analyze both individual projects and entire ecosystems to determine whether they are affected by known vulnerabilities, leveraging the OSV database's broad reach.

Unlike some other tools, OSV-Scanner focuses on vulnerability detection by parsing SBOMs or scanning a project’s dependencies to match them against its vulnerability database. It is particularly useful for projects that rely heavily on open-source libraries, ensuring that any newly reported security issues in third-party components are identified and addressed quickly.

For example, if an organization is using dozens of open-source libraries across multiple projects, OSV-Scanner can quickly identify which components have vulnerabilities and prioritize them for patching. This targeted approach to vulnerability management makes it an invaluable tool for maintaining secure open-source software.

Challenges in SBOM Adoption

While SBOMs offer significant advantages, their implementation presents several challenges—such as standardization, integration with legacy systems, and ongoing maintenance—that organizations must address to achieve seamless adoption.

Standardization

One of the biggest hurdles in SBOM adoption is the lack of a universal standard. Although formats like SPDX and CycloneDX are widely used, they serve different purposes and aren’t universally compatible. SPDX is focused on licensing, while CycloneDX leans toward security. This diversity of formats can cause problems when SBOMs are shared across organizations or systems. For instance, a company using SPDX may find it difficult to integrate SBOM data with a partner that uses CycloneDX. The absence of a single, unified standard results in interoperability challenges, making it harder to effectively exchange, analyze, or act on SBOM data across different platforms or industries.

This fragmentation also complicates tool integration, as each tool may support only certain formats, leading to gaps in the software lifecycle. Until a universally accepted SBOM format is established, organizations must navigate the complexities of handling multiple formats to ensure they maintain both compliance and security.

Legacy Systems

Another significant challenge lies in managing legacy systems. Many older software systems were developed before modern practices like dependency management and automated SBOM generation were common. These systems often lack proper documentation of their dependencies, making it difficult to generate an accurate SBOM. In some cases, manual cataloging of components is required, which is both time-consuming and prone to human error.

Legacy systems may rely on outdated or custom-built components that don’t fit neatly into modern SBOM tools, further complicating the process. This challenge is exacerbated by the fact that legacy systems are often deeply integrated into critical business operations, meaning even minor disruptions can have wide-reaching impacts. In such cases, organizations must invest significant time and resources into retrofitting these systems for SBOM compliance, sometimes requiring a complete overhaul of how dependencies are managed.

Maintenance

Generating an initial SBOM is just the first step; keeping it up-to-date as the software evolves is an ongoing challenge. Software is constantly changing—new features are added, dependencies are updated, and vulnerabilities emerge. Each of these changes must be reflected in the SBOM. Without a robust, automated system for updating SBOMs, the accuracy of the inventory can quickly degrade, leaving organizations exposed to security risks or compliance issues.

To address this, organizations need to integrate SBOM generation and updates tightly into their CI/CD pipelines. Automated tools must be used to ensure that every build and deployment includes a freshly updated SBOM. This level of automation requires careful planning and continuous monitoring to ensure that every change to the codebase—no matter how small—is captured in the SBOM. Without this integration, organizations risk having outdated SBOMs that fail to reflect the true state of their software.

Additionally, ongoing dependency management is crucial. Libraries and frameworks can evolve quickly, introducing new versions or security patches. Failing to update the SBOM as these changes occur can result in exposure to vulnerabilities or license issues. To mitigate this risk, organizations must not only automate the generation of SBOMs but also ensure that they are maintained throughout the entire software lifecycle.

The Role of OSPOs in SBOM Adoption

Open Source Program Offices (OSPOs) are central to the successful implementation of SBOM practices within an organization. OSPOs are responsible for governing the use of open-source software, ensuring that open-source adoption is secure, compliant with legal standards, and aligned with the organization’s broader risk management strategy. By promoting SBOM adoption, OSPOs embed a proactive approach to security and compliance within the software development lifecycle (SDLC).

Here’s how OSPOs contribute:

Governance and Compliance

A key responsibility of OSPOs is to ensure that the organization is using open-source components responsibly and legally. An SBOM enables OSPOs to track every third-party library, dependency, and module used in the organization’s software, providing a comprehensive view of all licenses involved. Open-source licenses come with various obligations and restrictions—ranging from permissive licenses like MIT to copyleft licenses such as GPL—which, if violated, can lead to legal risks.

With an SBOM, OSPOs can monitor and enforce license compliance across all software products, ensuring that the organization adheres to the terms of use for every open-source component. This allows OSPOs to avoid the risks associated with unintentional license violations and to ensure that the organization is in full compliance with external regulatory requirements. For example, if a GPL-licensed component requires source code disclosure, the OSPO can ensure compliance with this obligation.

Risk Management

In today’s rapidly evolving software landscape, where open-source software is both ubiquitous and vulnerable to supply chain attacks, risk management is paramount. OSPOs provide the governance structure to proactively identify and mitigate risks associated with open-source software. By embedding SBOMs into the development process, OSPOs ensure that every software build includes a detailed inventory of its components, along with visibility into potential vulnerabilities.

For example, OSPOs can use SBOMs to track the security status of third-party libraries and ensure that all components are up to date and regularly patched. When a new vulnerability is reported in a commonly used open-source library, the SBOM allows OSPOs to quickly identify where the affected component is used within the organization’s codebase. This empowers security teams to rapidly apply patches and reduce the organization’s exposure to threats.

OSPOs also ensure that risk management isn’t just reactive. By establishing policies for open-source software usage—such as which types of licenses and libraries are permissible—OSPOs set a proactive framework for minimizing risks before they arise.

Cross-Team Collaboration

One of the most critical roles of OSPOs is fostering collaboration between different departments within the organization, particularly development, security, and legal teams. OSPOs help break down silos by ensuring that SBOMs are not only used by developers during software creation but also by security teams for vulnerability tracking and legal teams for license compliance.

For instance, while developers may view SBOMs as a tool for dependency management, security teams can leverage the same SBOM to identify potential security risks. Legal teams, in turn, use SBOMs to ensure that the software complies with all relevant open-source licenses. This collaborative approach ensures that SBOMs serve multiple functions, benefiting all stakeholders involved in the software lifecycle.

By acting as a central hub, OSPOs ensure that the organization’s use of open-source software is consistent, secure, and compliant with both internal policies and external regulations. They create alignment across teams, ensuring that SBOMs are maintained as living documents that evolve with the software.

Emerging Global Software Bill of Materials (SBOM) Requirements

As global awareness of software supply chain security grows, governments and regulatory bodies in regions like the United States and the European Union are increasingly introducing SBOM requirements. These initiatives aim to promote transparency, enhance security, and ensure accountability across critical industries.

United States

In the U.S., the Securing Open Source Software Act and the National Cybersecurity Strategy are key drivers of SBOM adoption. These initiatives emphasize the critical need for generating and maintaining SBOMs to improve visibility into the components used in software, particularly in open-source projects. One of the most impactful shifts in the regulatory landscape is the introduction of liability for software vendors who fail to secure their software or fail to provide accurate SBOMs. This creates a level of accountability that encourages software developers and vendors to prioritize security throughout the software lifecycle.

Additionally, the FDA (Food and Drug Administration) now requires medical device manufacturers to include SBOMs as part of their regulatory submissions. The requirement is designed to ensure that all software components used in medical devices are monitored for vulnerabilities and kept up to date. This is particularly crucial in healthcare, where device security directly impacts patient safety. The inclusion of SBOMs ensures continuous monitoring, patch management, and greater visibility into the security posture of medical devices throughout their lifespan.

These U.S. regulations aim to establish a more secure and auditable software ecosystem by focusing on sectors like healthcare, finance, defense, and critical infrastructure, where software vulnerabilities can have catastrophic effects. By mandating SBOMs, the government is moving towards supply chain transparency, reducing the risks posed by third-party and open-source components that may be compromised or outdated.

European Union

In the European Union, SBOMs are gaining attention through regulatory frameworks such as the NIS2 Directive (Network and Information Security Directive) and the EU Cybersecurity Act. While these frameworks do not yet explicitly mandate the use of SBOMs, they emphasize the importance of securing software used in critical sectors, including energy, healthcare, and financial services. These regulations focus on enhancing security standards and encouraging companies to adopt best practices for managing software risks, including supply chain transparency.

The Cyber Resilience Act, currently under discussion in the EU, could introduce SBOM-related requirements for both software and hardware products sold in the EU market. The proposed regulation aims to ensure that products remain secure throughout their entire lifecycle, requiring continuous monitoring, updates, and transparency about the components used. Although not yet formalized, this act represents a potential shift toward making SBOMs a key compliance requirement within the EU.

If the Cyber Resilience Act is enacted, it would significantly impact software vendors and developers by requiring them to generate and maintain SBOMs for any product sold within the EU. This would align with the global trend toward greater accountability in the software supply chain, particularly in industries where cybersecurity is critical.

Conclusion: The Future of SBOMs in Open-Source Software

As the software landscape continues to evolve, Software Bill of Materials (SBOMs) are quickly becoming a cornerstone of secure software development and supply chain management. The growing reliance on open-source components, combined with increasing regulatory pressures, means that organizations need to prioritize SBOM adoption to safeguard against vulnerabilities, ensure compliance, and maintain transparency.

Looking ahead, the global push toward SBOM standardization—driven by initiatives in both the U.S. and the European Union—suggests that SBOMs will soon become a fundamental requirement across multiple sectors. As governments introduce liability for non-compliance and sectors such as healthcare and critical infrastructure demand higher levels of accountability, SBOMs will become indispensable tools for managing software risk.

Organizations that proactively integrate SBOMs into their software development lifecycle will be well-positioned to not only meet regulatory requirements but also improve their overall security posture. By leveraging open-source tools like Syft, CycloneDX-CLI, Dependency-Track, and OSV-Scanner, companies can automate SBOM generation and monitoring, making it easier to manage their software’s evolving landscape.

The role of OSPOs (Open Source Program Offices) will continue to expand as they champion SBOM practices across development, security, and legal teams. Their involvement will ensure that SBOMs are not just technical documents but active components of a broader strategy to ensure the secure and responsible use of open-source software.

As SBOM practices mature, we can expect even more sophisticated tools and standards to emerge, driving industry-wide adoption. The future of SBOM is one of increased accountability, global harmonization, and greater software security in a rapidly interconnected world. Organizations that adapt to these changes will find themselves at the forefront of innovation, security, and compliance in the digital age.

This article is part of the Regina Nkenchor Open Source and OSPO newsletter series, now with a growing community of subscribers. If you enjoyed this article, feel free to subscribe for updates on new releases. If you're new to open source and OSPO topics, I recommend starting with my first article on the intersection of Open Source, OSPOs, and Inner Source. My writing is progressive, catering to both beginners and experts. Articles from this series have been featured by the TODO Group, the InnerSource Commons Foundation, and This Week in GNOME. You can also check out my work on Github. Happy reading!