SBOM Best Practices for Embedded and Medical Software

Modern software is built on layers of open-source and third-party components—bringing both innovation and risk. In regulated industries, especially those handling sensitive data or critical systems, understanding exactly what’s inside your software is no longer optional.

That’s why Software Bill of Materials (SBOM) has become a key requirement for security, compliance, and supply chain transparency.

If you’re working in embedded or medical software development and need to implement or improve SBOM practices—for compliance, automation, or risk management—we’re here to help.

Let’s talk about how to simplify and scale SBOM management across your software lifecycle.

 

What is a Software Bill of Materials (SBOM)?

A Software Bill of Materials (SBOM) is essentially an inventory or list of all the components that make up a software product – often likened to a “list of ingredients” for software.

Formally, the U.S. government’s cybersecurity Executive Order 14028 defines an SBOM as “a formal record containing the details and supply chain relationships of various components used in building software.

In practice, an SBOM enumerates every open-source library, third-party module, and other dependency in your code, along with metadata like versions, licenses, and cryptographic hashes. This detailed transparency is crucial for understanding your software’s supply chain.

 

Why does an SBOM matter?

Software products include numerous third-party libraries and open-source components. An SBOM provides visibility into those components, which is invaluable for several reasons:

 

• Security & Vulnerability Management: When a new vulnerability is disclosed, organizations with SBOMs can quickly identify if that vulnerable component is in their products and where. SBOMs let teams track known or newly identified vulnerabilities across the software supply chain and respond rapidly. This visibility is essential for addressing emerging security threats posed by third-party components and unvetted dependencies.

 

• Compliance & Traceability: SBOMs facilitate compliance with industry regulations and standards by providing transparency and traceability in the event of a security incident or audit. Regulators and customers increasingly require SBOMs as proof of due diligence in managing supply chain risks.

 

• License Compliance: An SBOM lists the licenses of all components, helping ensure no copyleft or forbidden-license code sneaks into a product. Catching incompatible licenses early avoids costly remediation later.

 

• Supply Chain Transparency & Trust: By sharing SBOMs (with customers or auditors under appropriate confidentiality), software vendors demonstrate openness about what’s inside their product. This builds customer trust. Especially in safety-critical fields like medical devices, such transparency can be a competitive advantage.

In short, an SBOM acts as a foundation for software security and governance. It is increasingly viewed as “essential for managing software security and risk” by both governments and industry.

 

 

Regulatory Drivers: Why SBOMs Are Becoming Mandatory?

Multiple government regulations and industry standards now require or strongly recommend SBOMs, underscoring their importance for compliance. Key examples include:

 

• U.S. Executive Order 14028 (2021) – This cybersecurity directive requires federal agencies to obtain SBOMs for any software they use. It led to the definition of minimum SBOM elements and recognized standard formats like SPDX, CycloneDX, and SWID. If you supply software to the U.S. government, an SBOM is now a mandatory part of your deliverables.

 

• EU Cyber Resilience Act (CRA) – This upcoming regulation will require SBOMs for software and digital products sold in the EU. Manufacturers must include SBOMs in technical documentation and provide them to authorities on request. The CRA focuses on top-level dependencies and allows formats like SPDX 2.3+ or CycloneDX 1.4+. Full enforcement is expected by 2025–2026, making SBOMs a legal requirement for entering the EU market.

 

• FDA Premarket Cybersecurity (U.S. Medical Devices) – Since October 1, 2023, the FDA can reject medical device submissions that lack proper cybersecurity documentation, including an SBOM. For connected devices, the SBOM must list all software components (commercial, open-source, off-the-shelf), include support status and a vulnerability assessment, and follow a standard machine-readable format like SPDX or CycloneDX. Without it, regulatory approval may be denied.

 

• NTIA/NIST SBOM Standards – SBOM best practices are now backed by key standards bodies. NTIA and NIST have defined SBOM “minimum elements” and endorsed SPDX, CycloneDX, and SWID as baseline formats. CISA and industry frameworks (e.g. ISO/IEC, UNECE WP.29, PCI-DSS 4.0) increasingly require software transparency. SBOMs are shifting from optional to essential across sectors, becoming a cornerstone of modern software supply chain security.

 

Non-compliance risks

Failing to produce and maintain SBOMs where required can have serious consequences. These include regulatory penalties (or inability to sell your product in certain markets), liability exposure in the event of a breach (e.g. if it’s revealed you didn’t vet third-party components), and damage to business reputation.

 

SBOM Best Practices Across the Software Lifecycle

To reap the security and compliance benefits of SBOMs, software organizations should treat SBOM management as an integral part of their software development lifecycle. Here are best practices for generating, maintaining, and auditing SBOMs from development through deployment:

 

Automate SBOM Generation in CI/CD

Don’t rely on manual processes to create SBOMs. The best approach is to integrate SBOM generation into your continuous integration (CI) and delivery (CD) pipeline so that an up-to-date SBOM is produced on every build or release. Automation ensures no release is missing an SBOM and reduces human error.

For example, you can incorporate open-source SBOM tools (like Syft or CycloneDX plugins) into build scripts to emit an SBOM artifact for each build. This also enables you to set up release gates – e.g. the pipeline can automatically check the SBOM for any “unacceptable licenses or critical vulnerabilities” and fail the build if issues are found.

Automating SBOM creation means you’ll always have an accurate BOM for whatever code is running in test or production.

 

Maintain Up-to-Date and Accurate SBOMs

An SBOM is a living document that should reflect the current state of your software. It’s a best practice to update SBOMs whenever dependencies change or new releases are cut. Stale SBOMs (e.g. from last year’s product version) are of little use; frequent updates ensure your inventory is accurate for proactive vulnerability management and compliance audit.

It’s also critical to ensure SBOM completeness and accuracy – cross-check that the SBOM generated by your tools actually matches the components in the final build. This may involve auditing the SBOM against the software artifact (for example, verifying that all dynamically linked libraries in a firmware image are listed).

Conduct periodic SBOM audits and compare against package manifests or container contents to catch any omissions. Accuracy is paramount: an SBOM with missing components undermines its security value.

If using multiple SBOM types (e.g. a source SBOM from scanning source dependencies and a build SBOM from the compiled output), compare them to reconcile any differences.

 

Use SBOMs as a QA and Security Gate

Leverage SBOMs during testing and release candidate phases to improve software quality. In QA, treat the SBOM as an object for inspection: scan the SBOM’s components for potential vulnerabilities (using sources like NIST’s NVD or other advisory databases) and for license compliance before approving a release.

Many organizations now implement an “SBOM check” in their release checklist – e.g. verifying no components have high-severity CVEs open, and no new GPL-licensed library snuck in. These checks can be automated with tooling.

By coupling SBOM analysis with your QA process, you ensure that each release meets your security and legal policies—avoiding license violations and mitigating security risks. (no unpatched vulns, no license violations). This integration supports consistent security practices across your release pipeline.

It’s also wise to archive each SBOM and the results of these scans as an audit trail for compliance. That way, you have evidence showing what components (and vulnerabilities) were present in a given version of the product, and how they were evaluated, which can greatly streamline future audits or incident investigations.

 

 

Manage SBOMs Throughout Deployment

SBOM practices shouldn’t stop at release. In production and post-deployment, continue to use SBOMs for monitoring and maintenance. A best practice is to maintain an SBOM for every version of your software in use – whether running on embedded devices in the field or deployed at customer sites.

These SBOMs can be ingested by continuous monitoring tools to alert you if a new CVE emerges or if any components contain known security vulnerabilities. Essentially, storing SBOMs for deployed versions allows you to continuously track emerging risks: when a new vulnerability is announced, you can instantly pinpoint which product versions (and which customers or devices) are impacted by searching through your SBOM repository.

This speeds up remediation (e.g. prioritizing patch development or customer notifications for the affected products). In regulated industries like medical, you may also be required to have a process for post-market surveillance of vulnerabilities – SBOMs are the foundation of that process, since you can’t monitor what you don’t know you have.

Keep SBOMs updated if patches or updates are applied in the field, and use them to guide end-of-life decisions (knowing which obsolete components exist in older product lines, for instance).

 

Secure Handling of SBOM Files

Treat SBOMs as sensitive documents, because they can reveal exploitable details about your product’s makeup. Best practices for SBOM handling include digitally signing SBOM files (to ensure their integrity and authenticity) and controlling their distribution.

Store SBOMs in a secure repository and, when sharing with external parties or regulators, use trusted channels. The SBOM should be delivered to only authorized recipients (it’s common to share with customers under NDA or with regulators via secure portals).

Ongoing initiatives even consider SBOM encryption or access control for highly sensitive environments. While the CRA explicitly states manufacturers don’t have to make SBOMs public, you should still be prepared to provide them securely on request.

Also ensure your SBOMs are kept in sync with software release versions in configuration management, so there’s no confusion about which SBOM corresponds to which build (embedding an SBOM ID or URI in the product can help).

 

Align SBOM Efforts with Standards and Train Your Team

As SBOM generation becomes routine, make sure your approach aligns with emerging standards and regulatory expectations. For instance, if you’re targeting EU markets under CRA, you might generate a “top-level dependency” SBOM for compliance, but also maintain full dependency SBOMs as a best practice.

Adopting a standard format like SPDX or CycloneDX from the start will ensure your SBOMs meet common data requirements.

It’s also advisable to educate your development teams and DevOps on SBOM usage – developers should understand why SBOMs matter (e.g. how including a new library triggers an SBOM update, or how to interpret SBOM scan reports). Building a culture of transparency about component usage will make SBOM maintenance much easier.

Some organizations even designate an SBOM champion or use “SBOM as code” practices (treating SBOM configuration as part of the build pipeline code) to embed it in the team’s workflow.

 

SBOM Formats: SPDX, CycloneDX, SWID tags

SBOMs are only effective if they are standardized and machine-readable. Several formats have emerged as de facto standards for SBOM data, enabling interoperability between tools. The two most popular SBOM formats are SPDX (Software Package Data Exchange) and CycloneDX, with SWID tags also recognized (though used less in practice). Each has its strengths:

 

SBOM Format	Origin & Standardization	Supported File Formats	Notable Features & Use Cases
SPDX	Linux Foundation; ISO/IEC 5962:2021	Tag-Value, JSON, YAML, RDF/XML, Excel	Rich in license and copyright data (born for compliance). Widely adopted by large vendors (e.g. Microsoft, Google). Supports component hashes, external references (e.g. can link to vulnerability IDs). Great for open source compliance and multi-tool interoperability.
CycloneDX	OWASP (moving to ECMA standard)	XML, JSON, ProtoBuf	Focused on security and dependencies. Designed for cybersecurity use cases (tracks vulnerabilities, dependency graph). Fast-evolving with support for additional BOM types (hardware, services, machine learning models) and VEX statements. Popular in DevSecOps tools; ideal for vulnerability management and supply chain risk analysis.
SWID Tags	ISO/IEC 19770-2:2015 (ISO standard)	XML	Software Identification tags used in enterprise software inventory. Contains unique product identifiers, versions, and metadata, but not a full dependency list. Useful for tracking proprietary software installations. Limited use as an SBOM for development purposes due to lack of nested component detail.

 

Choosing a format

For most organizations, either SPDX or CycloneDX (or both) will suffice. Both are capable of representing the NTIA minimum SBOM elements (they just use slightly different field names), and both are widely supported by tools.

 

Automation tools

Numerous automated tools exist to generate and manage SBOMs in the above formats. Given our focus on C++ and Qt in embedded development, it’s worth noting some options:

 

Qt and SBOM

Starting with Qt 6.8, the Qt framework itself provides built-in SBOM generation. Qt’s build system can now output a “Build SBOM” document for each Qt module, included automatically in the Qt installation package.

These SBOMs (in SPDX 2.3 format) list every Qt library and all third-party components it uses, along with dependency relationships, version numbers, licenses, and even cryptographic hashes of the binaries.

When you install Qt via the online installer, you’ll find a set of SBOM files in the Qt/<platform>/sbom/ directory corresponding to the Qt modules you installed. This is a real-world example of how a vendor is helping developers streamline compliance: by providing SBOMs for the framework, it becomes much easier for you as a developer to incorporate Qt into a medical device or other regulated product and already have SBOM coverage for that portion of your software.

You can augment those SBOMs with your own application’s SBOM to have a complete picture. Qt’s SBOM includes useful info like the exact compiler version used, build timestamps, and component hashes, which aid in reproducibility and security auditing.

This demonstrates the industry trend – build tools and package managers are starting to emit SBOMs out-of-the-box. Other ecosystems (npm, Maven, etc.) have plugins to generate SBOMs during builds, and even C/C++ build systems can invoke SBOM generators as a post-build step.

 

Open-source SBOM generators

If your toolchain doesn’t natively support SBOM output, you can use dedicated SBOM generation tools. Syft, for example, is an open-source CLI tool by Anchore that can scan container images, filesystems, or code repos to produce an SBOM (in SPDX or CycloneDX). It’s handy for C++ development compiled into Linux packages or containerized deployments. Syft integrates with vulnerability scanners like Grype, linking SBOM generation to CVE scanning.

Another tool, Microsoft’s SBOM Tool, can detect components in a codebase and generate an SPDX 2.2 SBOM, including enrichment of license data via ClearlyDefined APIs.

There are also CycloneDX CLI tools (cdxgen) that create CycloneDX SBOMs for many languages and can even include things like infrastructure-as-code or GitHub Actions as part of a broader “X-BOM” concept. For embedded development, you might integrate these tools into your build or use them to scan final binaries/firmware for linked libraries.

 

Commercial solutions

Software Composition Analysis (SCA) platforms such as Synopsys Black Duck, Sonatype Nexus Lifecycle, Snyk, and Mend (WhiteSource) have added SBOM export capabilities. These can be integrated into CI pipelines to automatically produce SBOMs and even continuously update them as dependencies change. Some platforms allow hosting SBOMs in a central dashboard and can import third-party SBOMs (for example, if you receive an SBOM from a supplier). The advantage of commercial tools is usually enhanced policy enforcement, vulnerability alerts, and reporting around the SBOM (e.g. license risk reports). However, open-source tools are sufficient for many use cases, especially when paired with robust processes.

 

Continuous monitoring and VEX

To complement SBOMs, consider tools for VEX (Vulnerability Exploitability eXchange). A VEX document states whether a product is affected by a known vulnerability, and why or why not. For instance, if your SBOM shows OpenSSL 1.1.1 and a vulnerability is announced, you could issue a VEX saying “not impacted because the vulnerable function isn’t used.” Formats like CycloneDX and CSAF support VEX, and products like Azure or Red Hat tools can manage VEX data. While VEX is beyond the scope of SBOM itself, it’s an emerging best practice to distribute VEX statements alongside SBOMs to minimize false alarms and focus consumers on real risks. In regulated environments (e.g. FDA expects a vulnerability assessment with the SBOM), providing context via VEX can be very helpful.

 

SBOM as a Pillar of Software Regulatory Compliance and Security

For CTOs, COOs, project managers and security teams in software firms implementing SBOM best practices is now a strategic imperative. An SBOM is much more than a paperwork requirement; it is a tool for supply chain transparency, regulatory compliance, and proactive security management. By cataloging every component in your software, SBOMs let you prove compliance with laws like the EU CRA and FDA guidelines, while simultaneously hardening your products against supply-chain attacks and vulnerabilities.

 
 

Looking beyond compliance, SBOMs offer tangible business benefits: they reduce the effort of managing security across complex dependencies, they build trust with customers (who gain assurance that you know and care what’s inside your product), and they improve internal efficiency (e.g. faster incident response and easier component upgrades). The organizations that lead on SBOM adoption position themselves as secure and accountable suppliers in an ecosystem increasingly demanding transparency. Conversely, those who neglect SBOMs may find themselves barred from key markets or scrambling in the wake of the next zero-day vulnerability due to lack of insight into their own software.

Need help implementing SBOMs in your software development process? Let’s talk about how to make compliance, automation, and security work together in your pipeline.