The Role of SBOMs in Securing the Software Supply Chain in 2025

The role of Software Bill of Materials (SBOMs) in securing the software supply chain in 2025 is increasingly pivotal across industries, particularly in government, defense, automotive, and open-source ecosystems. SBOMs provide a detailed inventory of software components, enhancing transparency, vulnerability management, regulatory compliance, and overall cybersecurity posture. As software supply chains become more complex and interconnected, the need for comprehensive visibility into software components has never been more critical. This visibility is essential for identifying and mitigating risks, ensuring compliance with regulatory standards, and building trust among stakeholders.

Understanding SBOMs

A Software Bill of Materials is a formal record containing the details and supply chain relationships of various components used in building software. It lists all the components, libraries, modules, and dependencies that make up a software application, along with their versions, licenses, and origins. Think of an SBOM as a nutritional label for software; it provides a clear and detailed breakdown of what's inside, enabling users to make informed decisions about its safety and suitability.

For example, consider a popular web application like a content management system (CMS). An SBOM for this CMS would include a list of all the open-source libraries it uses, such as jQuery, Bootstrap, and various JavaScript frameworks. It would also detail the versions of these libraries, their licenses, and any known vulnerabilities associated with them. This information is crucial for developers, security teams, and end-users to assess the software's security posture and compliance with licensing requirements.

Components of an SBOM

An SBOM typically includes several key components:

1. Component Information: This includes the name, version, and unique identifier (such as a CycloneDX BOMRef or SPDX Document URI) of each software component. For example, an SBOM might list "jQuery 3.6.0" as a component, with a unique identifier to distinguish it from other versions.

2. Supplier Information: This details the supplier or maintainer of each component, including their contact information and any relevant certifications. For instance, the SBOM might list the maintainer of jQuery and provide a link to their official website.

3. License Information: This includes the licensing terms under which each component is distributed. For example, jQuery is licensed under the MIT License, which allows for free use, modification, and distribution.

4. Dependency Information: This outlines the relationships between components, indicating which components depend on others. For instance, a JavaScript framework might depend on jQuery for certain functionalities.

5. Vulnerability Information: This lists any known vulnerabilities associated with each component, along with their severity and potential impact. For example, an SBOM might indicate that a specific version of jQuery is vulnerable to a cross-site scripting (XSS) attack.

6. Metadata: This includes additional information about the SBOM itself, such as its creation date, format, and any tools or standards used to generate it. For instance, an SBOM might specify that it was generated using the CycloneDX format on a specific date.

Formats and Standards

Several formats and standards have emerged for creating and sharing SBOMs, each with its own strengths and use cases. Some of the most widely used formats include:

1. CycloneDX: Developed by the CycloneDX community, this format is designed to be lightweight, human-readable, and easy to integrate into existing tools and workflows. CycloneDX supports multiple serialization formats, including JSON, XML, and Protocol Buffers, making it highly versatile.

2. SPDX (Software Package Data Exchange): SPDX is an open standard for communicating software bill of materials information in a consistent and machine-readable format. SPDX supports a wide range of use cases, from open-source software to proprietary software, and is widely adopted in the industry.

3. SWID (Software Identification) Tags: SWID tags are a standardized way to identify software products and their components. They are often used in conjunction with other SBOM formats to provide additional context and metadata.

Generating SBOMs

Generating SBOMs can be done manually or automatically, depending on the complexity of the software and the tools available. Manual generation involves manually identifying and documenting each software component, which can be time-consuming and error-prone. Automated generation, on the other hand, uses tools and scripts to automatically identify and document software components, reducing the risk of errors and saving time.

For example, a development team might use a tool like Syft or CycloneDX to automatically generate an SBOM for their software application. These tools scan the application's codebase and dependencies, identifying and documenting each component and its associated metadata. The resulting SBOM can then be used to assess the software's security posture, compliance with licensing requirements, and overall quality.

Key Developments and Trends in 2025

1. Expanded Regulatory Adoption and Compliance Pressure

SBOM adoption is accelerating, especially within U.S. government and defense sectors, driven by mandates like Executive Order 14028 ("Improving the Nation's Cybersecurity"). This executive order requires software providers to submit SBOMs as part of acquisition processes, enhancing supply chain visibility and incident response capabilities. The order aims to improve the security of the software supply chain by mandating that software vendors provide SBOMs for their products, enabling government agencies to better understand and manage the risks associated with the software they use.

The automotive industry is another sector where SBOM adoption is gaining traction. With the increasing use of software in vehicles, automotive manufacturers are recognizing the need for greater transparency and security in their software supply chains. SBOMs help automotive companies comply with regulatory requirements, such as those related to cybersecurity and data privacy, and mitigate risks associated with software vulnerabilities. For instance, a car manufacturer might use an SBOM to track the software components in its infotainment system, ensuring that all components are up-to-date and free from known vulnerabilities.

Regulatory Landscape

The regulatory landscape for SBOMs is evolving rapidly, with new mandates and guidelines emerging from various government agencies and industry organizations. Some of the key regulations and guidelines include:

1. Executive Order 14028: This executive order, issued by the U.S. government, requires software providers to submit SBOMs as part of acquisition processes. It aims to improve the security of the software supply chain by mandating that software vendors provide SBOMs for their products, enabling government agencies to better understand and manage the risks associated with the software they use.

2. NIST SP 800-161: This guideline, published by the National Institute of Standards and Technology (NIST), provides recommendations for securing the software supply chain. It includes guidance on the use of SBOMs to enhance supply chain visibility and incident response capabilities.

3. ISO/IEC 29110: This international standard provides guidelines for the development and maintenance of software. It includes recommendations for the use of SBOMs to enhance software quality and security.

4. Automotive Industry Guidelines: The automotive industry has developed its own guidelines for the use of SBOMs, focusing on the unique challenges and requirements of the automotive sector. These guidelines aim to enhance the security and transparency of the software supply chain in the automotive industry.

Compliance Challenges

While the benefits of SBOM adoption are clear, organizations face several challenges in achieving compliance with regulatory requirements. Some of the key challenges include:

1. Data Normalization: Aligning SBOM data formats across varied vendors and multiple versions can be complex, making it difficult to compare and analyze the data. Organizations may need to invest in tools and processes to normalize SBOM data, ensuring consistency and accuracy.

2. Legacy Systems: Integrating SBOMs with legacy systems can be challenging, as these systems may not have SBOMs or may use outdated formats. Organizations may need to invest in upgrading or replacing legacy systems to achieve compliance with SBOM requirements.

3. Operational Complexity: Managing large volumes of SBOM data, particularly during zero-day threats, can be operationally complex. Organizations may need to invest in advanced tools and processes to manage SBOM data effectively, ensuring timely vulnerability response and software impact assessment.

2. Enhancing Security Throughout the Software Development Life Cycle (SDLC)

Integration of SBOM generation into continuous integration/continuous deployment (CI/CD) pipelines is becoming standard practice. This automation ensures that SBOMs are updated with every software build, enabling real-time vulnerability detection and compliance checks at each development stage. By integrating SBOM generation into the CI/CD pipeline, development teams can automatically generate SBOMs for each software build, providing continuous visibility into the software components and their associated risks.

For example, a financial services company developing a new mobile banking application might integrate SBOM generation into its CI/CD pipeline. With each build, the pipeline would automatically generate an SBOM, listing all the software components used in the application, their versions, and any known vulnerabilities. This information would be used to prioritize patch management and ensure that the application complies with relevant security standards and regulations.

CI/CD Pipeline Integration

Integrating SBOM generation into the CI/CD pipeline involves several key steps:

1. Component Identification: The first step is to identify all the software components used in the application, including libraries, modules, and dependencies. This can be done using tools like Syft or CycloneDX, which scan the application's codebase and dependencies to identify and document each component.

2. SBOM Generation: Once the components have been identified, the next step is to generate an SBOM for each software build. This can be done using tools like CycloneDX or SPDX, which automatically generate SBOMs in a standardized format.

3. Vulnerability Scanning: The generated SBOMs can then be scanned for known vulnerabilities using tools like OWASP Dependency-Check or Snyk. These tools compare the components listed in the SBOM against known vulnerability databases, such as the National Vulnerability Database (NVD), to identify any potential risks.

4. Compliance Checks: The SBOMs can also be used to perform compliance checks, ensuring that the software meets relevant regulatory requirements and licensing terms. This can be done using tools like FOSSA or Black Duck, which automate the process of compliance checking.

5. Continuous Monitoring: Finally, the SBOMs can be continuously monitored for changes and updates, ensuring that the software remains secure and compliant over time. This can be done using tools like Aqua Security or Twistlock, which provide continuous monitoring and alerting for SBOMs.

3. Challenges in SBOM Implementation

Despite clear benefits, several obstacles remain in the widespread adoption and effective use of SBOMs:

Data Normalization and Scale: Aligning SBOM data formats across varied vendors and multiple versions complicates risk analysis at scale. Different vendors may use different formats and standards for their SBOMs, making it difficult to compare and analyze the data. Additionally, the sheer volume of SBOM data can be overwhelming, especially for large organizations with complex software supply chains.

Legacy and Classified Systems: Government and defense face difficulties integrating SBOMs with legacy systems and managing sensitive or classified information. Legacy systems often use outdated software components that may not have SBOMs, making it challenging to gain visibility into their software supply chains. Furthermore, managing SBOMs for classified systems requires additional security measures to protect sensitive information.

Operational Complexity: Managing large volumes of SBOM data, particularly during zero-day threats, challenges timely vulnerability response and software impact assessment. Zero-day threats are vulnerabilities that are unknown to the software vendor and, therefore, not included in the SBOM. Managing these threats requires additional tools and processes to detect and mitigate risks in real-time.

Data Normalization

Data normalization is a critical challenge in SBOM implementation, as it involves aligning SBOM data formats across varied vendors and multiple versions. This can be complex, as different vendors may use different formats and standards for their SBOMs, making it difficult to compare and analyze the data. Organizations may need to invest in tools and processes to normalize SBOM data, ensuring consistency and accuracy.

For example, an organization might use a tool like CycloneDX or SPDX to normalize SBOM data, converting it into a standardized format that can be easily compared and analyzed. The tool might also include features for data enrichment, such as adding missing metadata or correcting errors, to ensure the accuracy and completeness of the SBOM data.

Legacy Systems

Integrating SBOMs with legacy systems can be challenging, as these systems may not have SBOMs or may use outdated formats. Organizations may need to invest in upgrading or replacing legacy systems to achieve compliance with SBOM requirements. Additionally, managing SBOMs for classified systems requires additional security measures to protect sensitive information.

For example, a government agency might need to upgrade its legacy systems to support SBOM generation and management. The agency might also need to implement additional security measures, such as encryption and access controls, to protect sensitive information in the SBOMs.

Operational Complexity

Managing large volumes of SBOM data, particularly during zero-day threats, can be operationally complex. Organizations may need to invest in advanced tools and processes to manage SBOM data effectively, ensuring timely vulnerability response and software impact assessment.

For example, an organization might use a tool like Aqua Security or Twistlock to continuously monitor SBOMs for changes and updates. The tool might also include features for automated vulnerability response, such as patching or isolating affected components, to ensure timely mitigation of risks.

4. Role of Artificial Intelligence (AI) and Open Source

AI is playing an evolving role in software supply chain security and SBOM management, though adoption is cautious due to cost and security risks. AI can be used to analyze SBOM data, identify patterns and anomalies, and predict potential risks. For example, an AI-powered tool might analyze SBOM data to identify software components that are commonly associated with vulnerabilities, enabling security teams to prioritize patch management and risk mitigation efforts.

The software industry is leveraging AI to enhance SBOM analysis, automate threat detection, and close gaps in supply chain transparency. For instance, an AI tool might analyze SBOM data to identify software components that are commonly associated with vulnerabilities, enabling security teams to prioritize patch management and risk mitigation efforts. Additionally, AI can be used to automate the generation and management of SBOMs, reducing the burden on development teams and improving the accuracy and completeness of the data.

Meanwhile, open-source software distributors increasingly adopt SBOMs, SLSA (Supply Chain Levels for Software Artifacts), and attestations to build trust and accountability in their software stacks. SLSA is a framework for securing the software supply chain by defining a set of security practices and controls. Attestations are digital statements that verify the authenticity and integrity of software artifacts, such as SBOMs. By adopting these practices, open-source software distributors can build trust with their users and stakeholders, demonstrating their commitment to security and transparency.

AI in SBOM Management

AI can play a crucial role in SBOM management, enabling organizations to analyze and manage SBOM data more effectively. Some of the key use cases for AI in SBOM management include:

1. Pattern Recognition: AI can be used to analyze SBOM data and identify patterns and anomalies, such as software components that are commonly associated with vulnerabilities. This can help security teams prioritize patch management and risk mitigation efforts.

2. Risk Prediction: AI can be used to predict potential risks in the software supply chain, such as the likelihood of a zero-day threat. This can help organizations proactively mitigate risks and improve their overall security posture.

3. Automated Vulnerability Response: AI can be used to automate vulnerability response, such as patching or isolating affected components. This can help organizations respond to vulnerabilities more quickly and effectively, reducing the risk of a security breach.

4. SBOM Generation and Management: AI can be used to automate the generation and management of SBOMs, reducing the burden on development teams and improving the accuracy and completeness of the data. For example, an AI tool might automatically generate SBOMs for each software build, listing all the software components used in the application, their versions, and any known vulnerabilities.

Open Source and SBOMs

Open-source software distributors are increasingly adopting SBOMs, SLSA, and attestations to build trust and accountability in their software stacks. These practices help open-source software distributors demonstrate their commitment to security and transparency, building trust with their users and stakeholders.

For example, an open-source software distributor might adopt SLSA to secure its software supply chain, implementing a set of security practices and controls to ensure the integrity and authenticity of its software artifacts. The distributor might also use attestations to verify the authenticity and integrity of its SBOMs, providing users with a digital statement that confirms the accuracy and completeness of the data.

5. Proactive Strategies Beyond Compliance

Industry experts emphasize that organizations must go beyond mere regulatory compliance and adopt proactive strategies to manage supply chain risks effectively. This includes continuous monitoring, better collaboration among stakeholders, and employing advanced technologies for early detection of hidden threats within the software supply chain.

For example, a healthcare organization might implement a proactive strategy for managing software supply chain risks by continuously monitoring its software components for vulnerabilities and collaborating with its software vendors to address any identified risks. The organization might also use advanced technologies, such as AI and machine learning, to detect and mitigate hidden threats in real-time.

Continuous Monitoring

Continuous monitoring is a key component of a proactive strategy for managing software supply chain risks. It involves continuously monitoring software components for vulnerabilities and other risks, enabling organizations to detect and mitigate threats in real-time. Continuous monitoring can be achieved using a variety of tools and technologies, such as:

1. Vulnerability Scanners: Vulnerability scanners can be used to continuously scan software components for known vulnerabilities, providing organizations with real-time visibility into their software supply chain risks.

2. Threat Intelligence: Threat intelligence can be used to continuously monitor for emerging threats and vulnerabilities, providing organizations with early warning of potential risks.

3. AI and Machine Learning: AI and machine learning can be used to analyze SBOM data and identify patterns and anomalies, such as software components that are commonly associated with vulnerabilities. This can help organizations proactively mitigate risks and improve their overall security posture.

Collaboration and Information Sharing

Better collaboration among stakeholders is another key component of a proactive strategy for managing software supply chain risks. This involves sharing information and best practices among stakeholders, such as software vendors, customers, and industry organizations, to improve the overall security of the software supply chain.

For example, a software vendor might collaborate with its customers to share information about known vulnerabilities and best practices for mitigating risks. The vendor might also participate in industry organizations, such as the Cloud Security Alliance or the Open Web Application Security Project (OWASP), to share best practices and collaborate on security initiatives.

Advanced Technologies

Employing advanced technologies is another key component of a proactive strategy for managing software supply chain risks. This involves using advanced technologies, such as AI, machine learning, and blockchain, to detect and mitigate hidden threats within the software supply chain.

For example, a financial services company might use blockchain technology to secure its software supply chain, providing a tamper-proof record of all software components and their associated metadata. The company might also use AI and machine learning to analyze SBOM data and identify patterns and anomalies, such as software components that are commonly associated with vulnerabilities.

Real-World Examples and Case Studies

Case Study 1: Government Agency

A U.S. government agency tasked with managing critical infrastructure decided to adopt SBOMs to enhance its software supply chain security. The agency faced challenges in gaining visibility into the software components used in its legacy systems, many of which were outdated and lacked SBOMs. To address this, the agency worked with its software vendors to generate SBOMs for all its software components, including legacy systems. The agency also implemented a continuous monitoring system to detect and mitigate vulnerabilities in real-time.

By adopting SBOMs, the agency was able to gain comprehensive visibility into its software supply chain, enabling it to identify and mitigate risks more effectively. The agency also improved its compliance with regulatory requirements, such as Executive Order 14028, and built trust with its stakeholders by demonstrating its commitment to security and transparency.

Implementation Steps

The agency took several key steps to implement SBOMs and enhance its software supply chain security:

1. Assessment: The agency conducted an assessment of its software supply chain, identifying all software components and their associated risks. This included legacy systems, which were particularly challenging due to their outdated components and lack of SBOMs.

2. Vendor Collaboration: The agency worked with its software vendors to generate SBOMs for all its software components, including legacy systems. This involved collaborating with vendors to identify and document each component and its associated metadata.

3. Continuous Monitoring: The agency implemented a continuous monitoring system to detect and mitigate vulnerabilities in real-time. This involved using tools like Aqua Security or Twistlock to continuously monitor SBOMs for changes and updates, providing real-time visibility into the software supply chain risks.

4. Compliance and Reporting: The agency ensured compliance with regulatory requirements, such as Executive Order 14028, by generating and submitting SBOMs as part of its acquisition processes. The agency also implemented reporting mechanisms to provide stakeholders with regular updates on its software supply chain security posture.

Case Study 2: Automotive Manufacturer

An automotive manufacturer recognized the need for greater transparency and security in its software supply chain as it increasingly integrated software into its vehicles. The manufacturer adopted SBOMs to track the software components in its infotainment systems, ensuring that all components were up-to-date and free from known vulnerabilities. The manufacturer also implemented a CI/CD pipeline that automatically generated SBOMs for each software build, providing continuous visibility into the software components and their associated risks.

By adopting SBOMs, the manufacturer was able to comply with regulatory requirements related to cybersecurity and data privacy and mitigate risks associated with software vulnerabilities. The manufacturer also built trust with its customers by demonstrating its commitment to security and transparency.

Implementation Steps

The automotive manufacturer took several key steps to implement SBOMs and enhance its software supply chain security:

1. Component Identification: The manufacturer identified all the software components used in its infotainment systems, including libraries, modules, and dependencies. This involved using tools like Syft or CycloneDX to scan the application's codebase and dependencies to identify and document each component.

2. SBOM Generation: The manufacturer generated SBOMs for each software build, listing all the software components used in the application, their versions, and any known vulnerabilities. This involved using tools like CycloneDX or SPDX to automatically generate SBOMs in a standardized format.

3. Vulnerability Scanning: The manufacturer scanned the generated SBOMs for known vulnerabilities using tools like OWASP Dependency-Check or Snyk. These tools compared the components listed in the SBOM against known vulnerability databases, such as the National Vulnerability Database (NVD), to identify any potential risks.

4. Compliance Checks: The manufacturer performed compliance checks to ensure that the software met relevant regulatory requirements and licensing terms. This involved using tools like FOSSA or Black Duck to automate the process of compliance checking.

5. Continuous Monitoring: The manufacturer continuously monitored the SBOMs for changes and updates, ensuring that the software remained secure and compliant over time. This involved using tools like Aqua Security or Twistlock to provide continuous monitoring and alerting for SBOMs.

Case Study 3: Financial Services Company

A financial services company developing a new mobile banking application integrated SBOM generation into its CI/CD pipeline. With each build, the pipeline automatically generated an SBOM, listing all the software components used in the application, their versions, and any known vulnerabilities. This information was used to prioritize patch management and ensure that the application complied with relevant security standards and regulations.

By adopting SBOMs, the financial services company was able to enhance the security of its mobile banking application, build trust with its customers, and comply with regulatory requirements. The company also improved its software development process by integrating SBOM generation into its CI/CD pipeline, enabling continuous visibility into the software components and their associated risks.

Implementation Steps

The financial services company took several key steps to implement SBOMs and enhance its software supply chain security:

1. CI/CD Pipeline Integration: The company integrated SBOM generation into its CI/CD pipeline, ensuring that SBOMs were automatically generated with each software build. This involved using tools like CycloneDX or SPDX to automatically generate SBOMs in a standardized format.

2. Vulnerability Scanning: The company scanned the generated SBOMs for known vulnerabilities using tools like OWASP Dependency-Check or Snyk. These tools compared the components listed in the SBOM against known vulnerability databases, such as the National Vulnerability Database (NVD), to identify any potential risks.

3. Compliance Checks: The company performed compliance checks to ensure that the software met relevant regulatory requirements and licensing terms. This involved using tools like FOSSA or Black Duck to automate the process of compliance checking.

4. Continuous Monitoring: The company continuously monitored the SBOMs for changes and updates, ensuring that the software remained secure and compliant over time. This involved using tools like Aqua Security or Twistlock to provide continuous monitoring and alerting for SBOMs.

5. Patch Management: The company prioritized patch management based on the vulnerabilities identified in the SBOMs, ensuring that the software components were up-to-date and free from known vulnerabilities. This involved using tools like Jenkins or GitLab to automate the patch management process.

Case Study 4: Healthcare Organization

A healthcare organization recognized the need for greater transparency and security in its software supply chain as it increasingly adopted digital health technologies. The organization adopted SBOMs to track the software components in its electronic health record (EHR) systems, ensuring that all components were up-to-date and free from known vulnerabilities. The organization also implemented a continuous monitoring system to detect and mitigate vulnerabilities in real-time.

By adopting SBOMs, the healthcare organization was able to comply with regulatory requirements related to cybersecurity and data privacy and mitigate risks associated with software vulnerabilities. The organization also built trust with its patients by demonstrating its commitment to security and transparency.

Implementation Steps

The healthcare organization took several key steps to implement SBOMs and enhance its software supply chain security:

1. Component Identification: The organization identified all the software components used in its EHR systems, including libraries, modules, and dependencies. This involved using tools like Syft or CycloneDX to scan the application's codebase and dependencies to identify and document each component.

2. SBOM Generation: The organization generated SBOMs for each software build, listing all the software components used in the application, their versions, and any known vulnerabilities. This involved using tools like CycloneDX or SPDX to automatically generate SBOMs in a standardized format.

3. Vulnerability Scanning: The organization scanned the generated SBOMs for known vulnerabilities using tools like OWASP Dependency-Check or Snyk. These tools compared the components listed in the SBOM against known vulnerability databases, such as the National Vulnerability Database (NVD), to identify any potential risks.

4. Compliance Checks: The organization performed compliance checks to ensure that the software met relevant regulatory requirements and licensing terms. This involved using tools like FOSSA or Black Duck to automate the process of compliance checking.

5. Continuous Monitoring: The organization continuously monitored the SBOMs for changes and updates, ensuring that the software remained secure and compliant over time. This involved using tools like Aqua Security or Twistlock to provide continuous monitoring and alerting for SBOMs.

6. Incident Response: The organization implemented an incident response plan to quickly detect and mitigate vulnerabilities in real-time. This involved using tools like Splunk or ELK Stack to provide real-time monitoring and alerting for SBOMs.

Summary

In 2025, SBOMs are a cornerstone for securing software supply chains by providing critical visibility into software components, enabling prioritized vulnerability management, and ensuring compliance with tightening regulations. While adoption is growing rapidly, especially in high-security sectors, challenges remain around data management, legacy integration, and operational complexity. The integration of AI and industry-wide initiatives in open source will further mature the SBOM ecosystem, making it a fundamental tool for building resilient, transparent, and trustworthy software supply chains.

As software supply chains continue to evolve and become more complex, the need for comprehensive visibility into software components will only increase. SBOMs provide a powerful tool for achieving this visibility, enabling organizations to identify and mitigate risks, comply with regulatory requirements, and build trust with their stakeholders. By adopting proactive strategies and leveraging advanced technologies, organizations can enhance their software supply chain security and build resilient, transparent, and trustworthy software ecosystems.

The future of software supply chain security lies in the adoption of SBOMs and the integration of advanced technologies, such as AI and blockchain, to enhance visibility, transparency, and security. Organizations that embrace these technologies and adopt proactive strategies will be better positioned to manage the risks associated with the software supply chain and build trust with their stakeholders. As the regulatory landscape continues to evolve, organizations must stay ahead of the curve by adopting SBOMs and leveraging advanced technologies to secure their software supply chains and build resilient, transparent, and trustworthy software ecosystems.