SBOM Best Practices: 7 Common SBOM Mistakes and How to Fix Them

TL;DR

• Derive or verify your SBOM from the shipped firmware image, since manifests miss statically linked and vendored code.
• Build to CISA's 2026 Minimum Elements: 17 data fields and every transitive dependency.
• Give every component a PURL or CPE, and match against more than NVD, which now enriches only a fraction of CVEs.
• Regenerate, version, and sign an SBOM for every release.
• Pair each SBOM with VEX, and check every supplier SBOM against the binary you received.

On July 29, 2026, CISA and its partners replaced the 2021 NTIA minimum elements for an SBOM, and the required data fields went from seven to 17. Plenty of SBOMs that passed review last year now fall short of the baseline.

That makes this a good moment to revisit SBOM best practices. Most SBOM mistakes trace back to two habits: inventorying the build plan, and treating the SBOM as a one-time compliance deliverable. Both leave the document out of step with the product that actually ships.

For device manufacturers, those gaps turn into findings. FDA premarket review under section 524B already requires an SBOM for cyber devices, and the EU Cyber Resilience Act, whose vulnerability reporting obligations took effect on September 11, 2026, makes the SBOM part of a product's technical documentation from December 11, 2027. Here are the seven mistakes we see most often, each paired with the practice that fixes it.

1. Documenting What You Declared Instead of What You Shipped

Best practice: Generate or verify every SBOM against the shipped firmware image, so the inventory matches the binary your customers actually run.

Open the build manifest for a typical connected device and you'll find the packages your developers declared. Open the firmware image and you'll find more: C libraries compiled in statically, open-source code copied into a vendor directory years ago, RTOS and board support packages from the chip vendor, and prebuilt binaries from suppliers who never sent source. None of those appear in a lockfile, so a manifest-based SBOM skips them.

This is the costliest SBOM mistake because it hides the components you're least likely to be tracking. An OpenSSL build statically linked into a vendor's management daemon won't trigger an alert if the SBOM never listed it.

CISA's Types of SBOM Documents (April 2023) separates source, build, and analyzed SBOMs for this reason. An analyzed SBOM is produced from the finished artifact, which makes it the type that reflects third-party binaries you didn't build yourself. The 2026 Minimum Elements add an SBOM Generation Context field so recipients can see whether an SBOM was generated before the build, during it, or after it, as with binary analysis of the shipped image .

We describe this as the difference between a declared SBOM and a derived one. A declared SBOM is a claim about intent. A derived SBOM, built from the shipped binary, is evidence of what the device contains. That distinction matters the day a market surveillance authority or FDA reviewer asks how you know the list is complete.

Our ground truth inventory page and our explainer on binary software composition analysis cover how derived SBOMs are built.

If you ship firmware, keep build-time generation in CI and add binary analysis of the release image as a release gate. Diff the two outputs. Every component that appears only in the analyzed SBOM is a gap in your supply chain records.

2. Building to the 2021 NTIA Checklist

Best practice: Build to CISA's 2026 Minimum Elements, which call for 17 data fields, every transitive dependency, and an explicit label on anything unknown or withheld.

If your SBOM template dates to 2021, it's missing more than half the current baseline. On July 29, 2026, CISA, NSA, FBI, and international partners published the 2026 Minimum Elements for an SBOM, which updates and replaces the NTIA list. Seven fields carried over, several under new names, and 10 are new.

Coverage changed too. The 2021 list accepted top-level dependencies, while the 2026 version expects every component, including transitive dependencies, at every level of the dependency tree. The EU Cyber Resilience Act sets its legal floor lower: Annex I, Part II(1) requires an SBOM in a commonly used, machine-readable format covering at the very least the product's top-level dependencies. Treat the CRA floor as the minimum an authority can enforce and CISA's coverage rule as the target that makes the SBOM usable during vulnerability response.

The update also retires the loose idea of "known unknowns." Authors should now state whether missing data is genuinely unknown or deliberately withheld, and recipients may treat an SBOM as incomplete when core component data is withheld.

One caveat: the 2026 guidance is voluntary and creates no new legal requirement. Expect it in procurement language and customer questionnaires anyway, the way the 2021 list spread. Our NTIA minimum elements explainer covers the original baseline.

3. Relying on Component Names Without Machine-Readable Identifiers

Best practice: Give every component at least one machine-readable identifier, such as a package URL or CPE, and match vulnerabilities against more than one data source.

Inconsistent naming has long been a common SBOM mistake, and it has gotten more costly since. An SBOM entry reading "openssl 1.1.1" means something to an engineer. A scanner needs a precise identifier, such as cpe:2.3:a:openssl:openssl:1.1.1w:*:*:*:*:*:*:*, to match it against advisories, because "1.1.1" covers every patch release from 1.1.1 through 1.1.1w. When names drift between suppliers, tools, and releases, matches fail silently, and a missed match looks exactly like a clean result.

CISA's 2026 guidance now calls for at least one software identifier per component and recommends formats such as CPE and PURL.

The data behind those identifiers is also thinning out. In April 2026, NIST changed how it runs the National Vulnerability Database: it now enriches only CVEs in CISA's Known Exploited Vulnerabilities catalog, software used by the federal government, and critical software under Executive Order 14028. Backlogged CVEs published before March 1, 2026 moved to "Not Scheduled." NIST cited a 263% increase in CVE submissions between 2020 and 2025. Unenriched CVEs arrive without the CPE product mappings that CPE-only matching depends on.

Embedded products feel this hardest. Much firmware code is C and C++ pulled from tarballs or vendor SDKs with no package manager, so there's no obvious PURL to assign. Record component hashes (now a minimum element), assign CPEs where they exist, and pull advisories from sources beyond NVD, including OSV, CISA KEV, and vendor security bulletins.

4. Treating the SBOM as a One-Time Compliance Snapshot

Best practice: Generate a new SBOM for every build or release in CI, version and sign it, and keep it retrievable for at least 10 years or the product's full support period, whichever is longer.

SBOM checklists often list "not updating" and "not automating" as separate mistakes. In practice they're one mistake. Teams that generate SBOMs by hand generate them once, usually the week before a submission, and the document is stale by the next patch.

CISA's frequency guidance calls for a new SBOM with each build or release. The 2026 fields make that traceable: SBOM Version marks a change from the previous document, and SBOM Author Signature lets a recipient confirm who produced it and that nobody altered it in transit.

For CRA-scoped products, the SBOM belongs to the technical documentation, which manufacturers must keep available to market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period if that is longer (Article 13(13)). The support period itself runs at least five years for most products (Article 13(8)). A firmware release from 2022 that's still in the field needs an SBOM you can retrieve and re-scan on demand.

A working setup has three parts:

• A CI job produces the SBOM alongside every release artifact and signs it with a dedicated key from your existing code-signing infrastructure.
• An artifact store keys each SBOM to its firmware version and hash.
• A scheduled job re-matches every stored SBOM against new advisories daily, so a CVE published tomorrow reaches products you shipped years ago.

Our integrations page shows how this fits into GitHub Actions, GitLab CI, and Jenkins pipelines.

5. Picking CycloneDX or SPDX Without Checking the Version

Best practice: Choose CycloneDX or SPDX based on what your regulators and customers request, then record and match the exact specification version they expect.

Teams spend weeks debating CycloneDX versus SPDX. Both are widely accepted, and CISA's 2026 document names them as the two formats in scope after dropping SWID. The mistake that actually breaks SBOM exchanges is a version mismatch. SPDX 3.0 uses a different data model from SPDX 2.x, so ingestion tools built for 2.3 often can't read it, and a contract citing ISO/IEC 5962:2021 is referring to SPDX 2.2.1.

Sources: CycloneDX 1.7 release notes, OpenSSF.

Two new CISA fields, SBOM Data Format Name and Data Format Version, exist to prevent this problem. Put both in every document, and confirm the version with each recipient before the first delivery. Older ingestion tools may not parse 1.7 documents, so a 1.6 document is the lower-risk default until a customer confirms their tooling reads 1.7.

The verdict: pick the format your highest-stakes recipient asks for. If two major customers disagree, generate both from the same scan data and skip hand conversion, which loses fields.

6. Shipping an SBOM Without Exploitability Context

Best practice: Pair each SBOM with VEX statements that say whether listed vulnerabilities affect the product, backed by reachability analysis of the shipped code.

Send a customer a raw SBOM and you've handed them a triage project. Their scanner matches every component against every advisory and returns a long list of CVEs, many of which can't be exploited in your product because the vulnerable function is never called or the feature is compiled out. Then the support tickets start.

VEX (Vulnerability Exploitability eXchange) closes that gap. A VEX statement tells the recipient, for a specific product and version, whether a listed vulnerability is affected, not affected, fixed, or under investigation. Paired with the SBOM, it answers the question customers actually ask: do I need to do anything?

A "not affected" statement needs a stated justification, such as the vulnerable code not being present or not being reachable, and evidence behind it. Reachability analysis traces whether vulnerable code paths are present and reachable in the shipped binary, which gives your PSIRT a defensible basis for the claim. See exploitability-based prioritization, our SBOM and VEX lifecycle management use case, and our explainer on how reachability analysis transforms vulnerability management.

The pressure to get this right rose on September 11, 2026, when the CRA's Article 14 reporting obligations took effect. Manufacturers now report actively exploited vulnerabilities in their products to the designated CSIRT and ENISA, starting with an early warning within 24 hours. The obligation also covers products already on the market. Fast reporting depends on fast triage.

Best for: any team distributing SBOMs to customers or regulators. Skip if: the SBOM stays internal and your own team is its only consumer, though you'll still want VEX for your own triage.

7. Accepting Supplier SBOMs Without Verifying Them

Best practice: Write SBOM requirements into supplier contracts, then check every supplier SBOM against an analyzed SBOM of the component you actually received.

A supplier SBOM is a claim from the party with the least incentive to find problems. Accept it unchecked and you inherit its blind spots, including every statically linked library the supplier forgot to declare.

Regulators put that responsibility on you. Under the CRA, manufacturers must exercise due diligence when integrating third-party components (Article 13(5)), which the regulation says can include checking security update history and known vulnerabilities, and vulnerability handling applies to the product in its entirety (Recital 34). In the U.S., section 524B(b)(3) of the FD&C Act requires cyber device manufacturers to provide an SBOM that includes commercial, open-source, and off-the-shelf software components, according to the FDA's cybersecurity FAQ. A supplier's gap becomes your gap in the submission.

Close it in two steps:

1. Contract for it. Specify format and version, the CISA 2026 fields, a per-release update cadence, and a notification timeline for new vulnerabilities.
2. Verify on receipt. Run binary analysis on the delivered firmware or library and diff the result against the supplier's SBOM. Send mismatches back to the supplier, and mark anything with no identifiable producer as unknown provenance.

For regulation-specific detail, see our guides to what the FDA's final guidance says about SBOMs and EU CRA SBOM and technical documentation.

If you're diffing supplier SBOMs by hand today, a binary-derived inventory does most of that work for you. Book a demo to see it run against your own firmware.

FAQ

What are SBOM best practices?

SBOM best practices are the habits that make a software bill of materials accurate enough to act on. The core set: derive or verify the SBOM from the shipped binary, meet CISA's 2026 minimum elements, use machine-readable identifiers, regenerate per release, record the exact format version, pair SBOMs with VEX, and verify supplier SBOMs. Each one maps to a mistake covered above, and together they turn the SBOM from a compliance file into a working input for vulnerability response and customer assurance.

How often should you update an SBOM?

Generate a new SBOM for every build or release, which is the frequency CISA's minimum elements describe. Separately, re-match stored SBOMs against new vulnerability data daily, because a component that was clean at release can pick up a new CVE at any point. Keep every SBOM retrievable for at least 10 years or the full product support period, whichever is longer, since fielded devices stay exposed long after the release ships.

Does the EU CRA require you to publish your SBOM?

No. Recital 77 of the Cyber Resilience Act states that manufacturers should not be obliged to make the SBOM public. The SBOM sits in your technical documentation, and from December 11, 2027, market surveillance authorities can request it. Many manufacturers still share SBOMs with customers under NDA or through a portal, because procurement teams increasingly ask for them.

How do SBOM best practices differ for embedded firmware and containers?

Container images usually carry package-manager metadata (apk, dpkg, rpm) that tools read directly from image layers, so image-based SBOMs capture most components. Software compiled from source or copied into the image as a prebuilt binary leaves no package-manager records, though. Embedded firmware often lacks that metadata: statically linked C libraries, vendored code, and vendor SDK blobs leave no package records.

For firmware, binary analysis of the release image is the dependable way to catch those components. Container SBOMs still need identifier and version discipline, so mistakes #3 through #5 apply to both. See mistake #1 above for the firmware detail.

Is the CISA 2026 minimum elements guidance mandatory?

No. CISA's 2026 Minimum Elements are voluntary and create no new legal or regulatory requirement. They matter anyway, because procurement teams, federal agencies, and other regulators tend to adopt them as the reference point, as happened with the 2021 NTIA list. The FDA hasn't announced whether it will align its SBOM recommendations to the new fields, so medical device teams should track both baselines for now.