Expanding the Bill of Materials

Traditionally, SBOMs list dependencies such as software, but modern BOMs also include cloud infrastructure, hardware, containers, and APIs, among others. Security teams are also expanding this list to the entire tech stack.

• Hardware Bill of Materials (HBOM) is used to track physical components in a device or embedded system, which is critical in IoT, telecom, and manufacturing, where firmware vulnerabilities and hardware backdoors can put networks at risk.
• Configurable Bill of Materials (CBOM) is used to track cloud infrastructure, containers, and services, providing visibility into cloud-based supply chain risk.
• Application Bill of Materials (ABOMs) track application services such as APIs and microservices, which are not directly controlled but can pose a significant risk if misconfigured or compromised.

Standards are also evolving, such as CycloneDX, which has introduced BOMs for machine learning models, cryptographic assets, and Software-as-a-Service (SaaS) from external sources. These BOMs can help in assessing all dependencies and their impact on application security.

Integrating Security into DevSecOps Pipelines

Traditionally, the concept of a software bill of materials has been viewed as a static document generated during software development. In fact, supply chain security is a continuous process that must be enabled across the software lifecycle with the help of DevSecOps. In this process, security tools can be integrated into the software development lifecycle to make security a continuous process with checks at every stage of development for source code, dependencies, containers, and infrastructure.

Automated generation of SBOMs in CI/CD environments with integrations to vulnerability databases like Common Vulnerabilities Exposure (CVE) can be used to compare the generated SBOMs with vulnerability databases. This can be used to quickly identify impacted applications in case of new vulnerabilities. However, detection of vulnerabilities is not sufficient. We need to assess

exploitability in the environment as well. In this regard, VEX can add value to the process by providing contextual risk information."

DevSecOps can be used to integrate code signing, integrity verification of artifacts, and build provenance to prevent tampering. Automated generation of security intelligence can be achieved by combining security tools with the generation of software bills of materials.

Threat Intelligence and Continuous Monitoring

However, even with such pipelines and expanded BOMs, supply chain security is a continuous process because new vulnerabilities and techniques are constantly being developed. This is where threat intelligence platforms come in handy because they continuously monitor global vulnerability feeds and malware research.

This means that organizations are able to assess and respond if a new vulnerability is introduced in a component already identified as secure by the SBOM.

New techniques are also being developed and identified by modern threat intelligence platforms, including new techniques such as malicious open-source packages, dependency poisoning, and typosquatting, which involve attackers releasing fake packages of libraries to mislead developers.

There is also risk involved with container ecosystems because security tools are constantly checking container images for malware, crypto-mining scripts, and even scripts that are hidden in public images.

There is also an assessment of the health of open-source software, including patch rates and maintainer reputation, which is often used to evaluate long-term component security. With SBOMs and continuous threat intelligence and software composition analysis, supply chain security is a continuous process rather than a one-time activity.

Governance and Organizational Responsibility

Security in the supply chain does not only entail technology. Governance and processes are involved as well. Supply chain security is a policy, collaboration, and risk management

challenge. 

There is a need to be aware of how to interpret the SBOMs and respond to risks. Collaboration in security, development, procurement, and legal affairs in enforcing supply

chain security policies and vendor requirements is necessary.

Regulatory frameworks have enhanced this responsibility. NIST, CISA SBOM, and the EU Cyber Resilience Act has prompted organizations to heighten supply chain security. SBOMs must be considered in secure development, vendor risk management, automated testing, and continuous monitoring. They must not be isolated.

SBOMs are a necessary starting point for supply chain security, but they are not sufficient on their own. The practical goal is to turn visibility into control: establish end-to-end provenance for builds, continuously evaluate vulnerability and exploitability in your environment, and enforce policy-driven safeguards before release.

In practice, that means SBOMs must be generated continuously and enriched with applicability context so teams can prioritize what is truly reachable and high-risk. Visibility must also extend beyond software dependencies to cloud infrastructure, hardware, and firmware, and application-layer services such as APIs and microservices.

Integrity controls such as artifact verification and build provenance should be treated as standard safeguards, not optional maturity goals. Finally, continuous monitoring and threat intelligence must inform response as the ecosystem shifts, while governance ensures supplier requirements, remediation timelines, and accountability are enforced across the organization.

When SBOMs become part of a living control system rather than a static compliance artifact, organizations can reduce supply chain risk at the same pace as modern software is built and shipped.