SBOM Consulting: Software Bill of Materials Implementation
A Software Bill of Materials (SBOM) is a structured inventory of the software components in a product, including third-party and open-source dependencies. It has moved from best practice to regulatory expectation: the Cyber Resilience Act requires manufacturers to maintain an SBOM covering top-level dependencies, and OEMs increasingly request one as part of supplier evidence. PRAETORIO helps embedded and industrial manufacturers implement SBOM generation, choose an appropriate format, and build a process that keeps it accurate as products evolve.
An SBOM is only useful if it is accurate and maintained: a one-time export that goes stale after the next firmware release does not meet the intent of the requirement, however it looks on paper.
Talk to Us About Implementing SBOM for Your Product LineWhat an SBOM Is
A Software Bill of Materials is a formal, machine-readable inventory listing the software components that make up a product: direct dependencies, transitive dependencies, their versions, licenses, and origin. For embedded and industrial products, this typically spans firmware, operating system components, third-party libraries, and open-source packages pulled into the build.
Two SBOM formats are in common use and both are widely tool-supported: SPDX (Software Package Data Exchange, standardized as ISO/IEC 5962) and CycloneDX, developed under OWASP with a stronger original focus on security use cases. Regulatory and customer requirements generally accept either format as long as it is machine-readable and complete enough to identify components and versions.
An SBOM supports several downstream uses beyond simple inventory: vulnerability management (matching components against disclosed CVEs), license compliance, and supply chain risk assessment.
Why SBOM Matters
It is now a regulatory requirement, not just good practice. The Cyber Resilience Act’s essential requirements include maintaining an SBOM covering at least top-level dependencies, in a commonly used, machine-readable format, as part of the technical documentation supporting conformity.
It is the foundation for vulnerability response. When a new CVE is disclosed for a widely used library, an accurate SBOM is what lets a manufacturer quickly determine which products are affected: without one, this becomes a manual, error-prone search.
Customers and OEMs increasingly require it. Supplier qualification and audit processes are adding SBOM as a standard evidence requirement, independent of any specific regulatory mandate.
Embedded and industrial products have a harder SBOM problem than typical software. Cross-compiled toolchains, vendored code, board support packages, and firmware blobs from silicon vendors make dependency tracking less straightforward than for a typical application built with a modern package manager: generic SBOM tooling often needs adaptation.
A stale SBOM is a liability, not an asset. An SBOM that isn’t regenerated as the product changes creates a false sense of coverage and can misdirect vulnerability response.
Our Approach
PRAETORIO implements SBOM as a sustainable engineering process, not a one-time deliverable:
- Build and dependency inventory: map the actual build process, toolchains, and dependency sources (package managers, vendored code, board support packages, third-party binaries) to understand what an SBOM needs to capture.
- Format selection: choose between SPDX and CycloneDX (or generate both) based on downstream tooling, customer requirements, and regulatory expectations.
- Tooling selection and integration: select SBOM generation tooling appropriate to the build system, and integrate it into the build or CI pipeline so SBOM generation happens automatically rather than manually.
- Baseline SBOM generation: produce an initial, accurate SBOM for the current product baseline, resolving gaps where automated tooling cannot see certain dependencies (e.g., vendored or binary-only components).
- Vulnerability matching integration: connect the SBOM to a vulnerability database or scanning tool so newly disclosed CVEs can be matched against the component inventory.
- Maintenance process definition: define how the SBOM is regenerated and reviewed as part of the release process, so it stays current with each product version.
- Documentation and delivery format: package the SBOM appropriately for its intended audience: regulatory technical documentation, customer delivery, or internal vulnerability management use.
Deliverables
- Build and dependency inventory report
- SBOM format recommendation (SPDX / CycloneDX)
- Integrated SBOM generation tooling in the build or CI pipeline
- Baseline SBOM for current product release
- Vulnerability matching setup against the SBOM
- SBOM maintenance process documentation
How PRAETORIO Can Support Your Team
- First-time SBOM implementation, establishing tooling and process for a product or product line that has never generated one.
- SBOM tooling integration, adding automated SBOM generation to an existing build or CI/CD pipeline.
- Gap resolution for embedded builds, addressing the vendored code, cross-compiled toolchains, and binary-only components that generic SBOM tools often miss.
- SBOM-to-vulnerability-management integration, connecting SBOM output to a vulnerability scanning or matching process.
- Format migration or dual-format generation, supporting manufacturers who need to produce both SPDX and CycloneDX for different customers or regulatory contexts.
- SBOM maintenance process design, ensuring the SBOM is regenerated and reviewed as part of the normal release process rather than treated as a one-off artifact.
Typical Use Cases
- A manufacturer implementing SBOM for the first time to meet Cyber Resilience Act technical documentation requirements.
- An embedded product team whose existing SBOM tooling (built for typical application software) doesn’t handle cross-compiled firmware or vendored code correctly.
- A supplier being asked by an OEM or Tier-1 customer to deliver an SBOM as part of a component or software delivery.
- An organization that generated an SBOM once as a one-time exercise and needs to make regeneration part of its standard release process.
- A company needing to connect its SBOM to a vulnerability management process to respond faster to newly disclosed CVEs affecting third-party components.
- A manufacturer needing to decide between SPDX and CycloneDX, or generate both, for different downstream requirements.
Why PRAETORIO
- Embedded systems background means we understand the specific SBOM challenges of cross-compiled toolchains, board support packages, and vendor-supplied binary components: not just typical application dependency trees.
- More than 15 years of experience in automotive and embedded software development, including AUTOSAR-based systems where dependency and component tracking is already a core discipline.
- Practical integration experience connecting SBOM generation to build pipelines and vulnerability management processes, not just producing a one-time export.
- Engineering-oriented delivery: SBOM implementation is built to survive the next product release, not just the next audit.
Related Services
- Cyber Resilience Act Consulting: the regulatory driver for SBOM requirements
- CRA Compliance: SBOM as part of the full compliance program
- Vulnerability Management: using the SBOM for vulnerability response
- PSIRT: incident response supported by accurate component inventory
- Cybersecurity Engineering: the overall cybersecurity engineering practice
- Embedded Cybersecurity: broader embedded and automotive cybersecurity engineering
FAQ
What is a Software Bill of Materials (SBOM)?
An SBOM is a formal, machine-readable inventory of the software components in a product, including direct and transitive dependencies, their versions, licenses, and origin. It supports vulnerability management, license compliance, and regulatory technical documentation.
Which SBOM format should I use, SPDX or CycloneDX?
Both are widely supported, machine-readable formats. SPDX (standardized as ISO/IEC 5962) has broader general adoption, while CycloneDX was developed with a stronger original focus on security use cases. The right choice often depends on customer or regulatory requirements and existing tooling; some organizations generate both.
Does the Cyber Resilience Act require an SBOM?
Yes. The CRA’s essential requirements include maintaining a Software Bill of Materials covering at least the top-level dependencies of a product, in a commonly used, machine-readable format, as part of the technical documentation supporting conformity.
Why is SBOM generation harder for embedded and industrial products?
Embedded builds often involve cross-compiled toolchains, vendored code copied directly into a source tree, board support packages, and binary-only components from silicon vendors. Generic SBOM tooling built for typical application dependency managers often cannot see these components without adaptation.
How often should an SBOM be regenerated?
Ideally, as part of every release: an SBOM tied to a specific product version is only accurate for that version. Integrating SBOM generation into the build or CI pipeline is the most reliable way to keep it current without relying on someone remembering to regenerate it manually.
Can an SBOM help with vulnerability response?
Yes. When a new vulnerability is disclosed for a widely used library, an accurate SBOM lets a manufacturer quickly determine which products include the affected component and version, rather than manually searching through build configurations and dependency lists.
Can PRAETORIO help if we already have a partial or outdated SBOM?
Yes. Engagements commonly start with an existing but incomplete or stale SBOM, and focus on closing gaps (particularly around vendored or binary components), integrating generation into the release process, and connecting the SBOM to vulnerability management.
Need to Implement or Mature Your SBOM Process?
PRAETORIO can support your team from initial dependency mapping through tooling integration and ongoing SBOM maintenance. Contact us to discuss your product’s SBOM requirements.
Contact Us