How to Create a Compliant Software Bill of Materials (SBOM) for SoC and System Design

In the semiconductor world, “software" is more than just application code. It is a complex stack of firmware, bootloaders, microcode, drivers, and Board Support Packages (BSPs) that are intricately linked to the hardware being designed. To secure the supply chain, meet customer expectations, and maintain market access, semiconductor leaders need a dynamic, "living" SBOM strategy that assesses risk in real-time and provides a single source of truth for all teams to work from.  

This guide outlines the elements of an SBOM, explores the current regulatory environment, and explains how to create a comprehensive, regulation-ready SBOM tailored for the demanding semiconductor supply chain. It covers how to manage the convergence of software, hardware, and firmware, and how to operationalize your process using a dedicated SBOM tool like Perforce IPLM. 

Defining an SBOM for 2026 and Beyond 

What is a Software Bill of Materials (SBOM) as it applies to semiconductor and system design? For today’s advanced design teams, it should be a comprehensive and machine-readable inventory of all software components, dependencies, and metadata included in the final product.  

A fully realized SBOM provides complete transparency into what’s inside a software stack. It merges traditional Bill of Material (BOM) data with semiconductor-specific criteria so that both hardware and software teams can track software provenance, ensure regulatory compliance, and quickly address security vulnerabilities or licensing issues. 

Elements of a Modern SBOM  

• Component Details: Names, versions, and unique identifiers for all software components, including third-party libraries and open-source dependencies.
• Dependency Mapping: A clear hierarchy of top-level and transitive dependencies to provide a full picture of how the components interact.
• Licensing Information: Software license details needed to ensure compliance and avoid legal risks.
• Vulnerability Information: Known vulnerabilities (e.g., CVEs) associated with each component to aid in risk management and patching.
• Cryptographic Hashes: Unique hashes for verification and validation of software integrity.
• Supply Chain Data: Information about the origin and chain of custody for third-party IPs or binaries.
• Lifecycle Metadata: Dates of inclusion, updates, and deprecation for each component. 

The System on Chip SBOM: Software and Firmware

Additionally, modern teams must define their SBOM’s scope to bridge the gap between hardware and software. For a modern system on chip (SoC), "software" includes:

• Firmware & Microcode: The low-level instructions that control hardware behavior.
• Bootloaders: Trusted execution environments (TEE), U-Boot, and secure boot chains.
• Drivers & BSPs: The Board Support Packages that allow the OS to talk to the silicon.
• Operating Systems: Embedded Linux, RTOS, or Android distributions shipped with reference designs.
• Third-Party Blobs: Binary-only drivers for GPUs or radios where source code is unavailable.

A comprehensive SBOM must capture and map these elements to the specific hardware IP versions they support.  

Example: If your SBOM lists a driver version but fails to link it to the specific revision of the hardware IP it controls, you will be prone to unflagged bugs or security risks associated with the change.  

Binary-First Analysis

Ideally, SBOMs are generated from source code during the build process. However, the semiconductor supply chain often involves "binary blobs” with compiled code provided by third-party vendors and without source access. A robust SBOM strategy must include binary analysis capabilities to decompose these blobs and create a complete inventory of their contents so that no hidden vulnerabilities enter your final design. 

Meeting Compliance with SBOMs 

The shift from voluntary transparency to mandatory compliance is here. Global regulators are enforcing strict standards to secure the technology supply chain, including all software and firmware materials. A comprehensive SBOM is crucial to meeting compliance with these emerging standards impacting semiconductor production:

CISA’s “Minimum Elements” and 2025 Outlook

The Cybersecurity and Infrastructure Security Agency (CISA) has moved the goalposts significantly since the 2021 Executive Order 14028. The focus is now on "Minimum Elements,” or the baseline data fields required to effectively track security risks. For semiconductor firms, this means your SBOM cannot just list "Firmware v1.0." It must be machine readable (SPDX or CycloneDX) and detail the specific components within that firmware, including third-party libraries, open-source stacks, and cryptographic modules.

The EU Cyber Resilience Act (CRA)

The EU’s Cyber Resilience Act represents the most significant shift in the market. By 2027, products with digital elements sold in the EU must bear the “CE” marking, signifying compliance with cybersecurity requirements. This includes the ability to deliver SBOMs and vulnerability patches for the expected product lifetime. For chipmakers, non-compliance means being locked out of the European market.

U.S. Federal and DoD Requirements

The U.S. Department of Defense (DoD) and other federal agencies are actively tightening procurement rules with a shift toward continuous monitoring. Federal acquisition rules will require prime contractors and their distinct subcontractors (down to the chip level) to provide proof of software provenance. 

Future Considerations: CBOM and AIBOM

As SoCs evolve into AI-enabled platforms, the definition of the Bill of Materials will expand with them. Semiconductor architects must plan for evolving regulations in these new territories:

• CBOM (Cryptographic Bill of Materials): With the approach of post-quantum cryptography standards, customers need to know exactly what cryptographic algorithms reside in your hardware and firmware. A CBOM inventories cryptographic assets and identifies vulnerabilities in standards (like RSA-2048) and allows you to instantly identify every piece of firmware relying on that standard so that you can plan a remediation strategy.
• AIBOM (AI Bill of Materials): For chips with on-device AI or neural processing units (NPUs), regulatory bodies seek transparency regarding the AI models, weights, and training data provenance embedded in the firmware. An AIBOM tracks the provenance of AI models, including the training data used, the model weights, and the biases inherent within the system.  

Dynamic Risk Management Through a Living Document

A static PDF export of an SBOM is obsolete the moment it is generated. Modern SoC and system development requires a dynamic document that evolves with every code commit, hardware respin, and nightly build. A secure, automated SBOM that updates automatically with every change is key to successful design cycles.

Automation via CI/CD

Native SBOM generation should be integrated directly into your CI/CD pipelines. Every time a new firmware build is triggered or a new RTL version is verified, the SBOM should automatically update. This allows teams to instantly see what changed and if new vulnerabilities were introduced.

VEX: Contextualizing Vulnerabilities

Finding vulnerabilities is inevitable; how you manage them is crucial. The Vulnerability Exploitability eXchange (VEX) is a companion artifact to the SBOM that allows vendors to communicate the status of each vulnerability.

Example: Instead of letting a customer’s scanner flag a "Critical" CVE in a library you use, a VEX document allows you to certify: "We use this library, but the vulnerable function is not called in our implementation." This reduces noise and builds trust. 

The Solution: Operationalize Your SBOMs with Perforce IPLM

The challenge for most semiconductor companies is not understanding what an SBOM is, but how to generate one accurately when design data is scattered across different repositories (Perforce, Git, Subversion) and silos (hardware vs. software).

Perforce IPLM treats software, firmware, and hardware designs as managed IP objects within a unified ecosystem. This enables a hierarchical bill of materials that accurately represents the complexity of your silicon with individual permissions for every team member.  

The Project BOM  

Perforce IPLM manages a project BOM. This is a hierarchical structure that mirrors the design itself. A top-level SoC object in IPLM contains references to all sub-IPs (CPU cores, SerDes, Memory Controllers) and the associated software stacks.

Because IPLM sits above the file management layer, it acts as a single source of truth. It consolidates metadata from hardware and software teams into one federation. When it’s time to generate an SBOM, you aren't manually collating lists; you are simply exporting the current state of the project BOM into a standard format like SPDX or CycloneDX.

The "Six Ws" of High-Value Metadata

A high-value SBOM relies on rich metadata. Perforce IPLM natively captures the Six Ws for every IP in the hierarchy, ensuring total traceability:

• Who: Who owns this IP? (Author/Owner)
• What: What version and configuration is used? (Version/Variant)
• Where: Where does the source live? (Repository path/Branch)
• When: When was it integrated or released? (Timestamp/Lifecycle state)
• Why: Why was this specific version chosen? (Requirement ID/Change Request)
• How: How was it built? (Toolchain version/Compiler flags)

Example: When a verification engineer looks at an SoC, they can trace the specific version of the USB driver back to the specific version of the USB hardware IP it supports.

Permissions and Auditability

Regulatory compliance isn't just about what is in the code, but also who touched it. Perforce IPLM’s granular permissions allow you to restrict IP access based on geography and user roles. Your SBOM is proof that specific cryptographic modules or export-controlled IPs were only accessed by authorized engineers in permitted locations. 

3 End-to-End Workflows with Perforce IPLM

Perforce IPLM embeds a fully automated, auditable SBOM directly into your daily engineering flows:

1. The "Design" Workflow

The SBOM process begins during IP selection. Using the IPLM Catalog, designers select validated IP blocks (e.g., a specific ARM core, a PCIe controller, or a USB driver). Because IPLM stores metadata (the Six Ws) alongside the design data, the foundation of the SBOM is built automatically starting on day 1 as you begin to define your chip’s architecture. 

2. The "Change and Rework" Workflow

In semiconductor design, change is constant. An error in a hardware block or a patch in a driver can trigger costly delays and lost work. IPLM provides:

• Traceability: When a hardware IP version changes in IPLM, the system flags its dependencies.
• Impact Analysis: You can instantly query, "Where is this IP used?" and identify every affected SoC and software build.
• Regeneration: The system updates the BOM and regenerates the SBOM artifacts. This ensures that when a security team asks about a specific change or bug, you can answer with 100% confidence based on the current configuration, not outdated documentation.

3. The "Compliance" Workflow

To meet regulatory requests, security teams can query IPLM for a specific product configuration and export a machine-readable SBOM that spans the entire hardware-software stack. You can trace a specific binary back to its source code, the requirements it fulfilled, and the tests it passed. Keep precise records to comply with requests even years into the design. 

Transform Complexity and Compliance into an Advantage

Creating and managing a complete software bill of materials is a requirement for doing business with governments and highly regulated industries. However, it can also provide a competitive advantage. By operationalizing your SBOM using Perforce IPLM, you transform it into a strategic asset.  

For semiconductor companies, this means using SBOMs to bridge the historical divide between hardware and software workflows through an IP-centric methodology. By leveraging tools like Perforce IPLM, organizations can automate the creation of the CIPB, ensure end-to-end traceability, and turn compliance from a burden into a hallmark of quality.  

Talk to one of our BOM experts to learn how IPLM can transform your design process with streamlined compliance, fewer errors, and automated, audit-ready SBOMs.  

Talk to an Expert 

Related Reading

Explore additional BoM content:

• What Is a Planning BoM?
• Creating a System BoM for Software Development