Every SBOM compliance conversation eventually collides with the same wall: a spreadsheet full of component names, no version pinning, and a security team that finds out about a dependency after it's already shipped to production. In May 2021, Executive Order 14028 made SBOMs a formal requirement for anyone selling software to the U.S. federal government, and the NTIA's "minimum elements" guidance turned a niche packaging practice into a compliance obligation. Since then, the EU Cyber Resilience Act, FDA premarket cybersecurity guidance, and PCI DSS 4.0 have all added their own SBOM expectations. Yet most organizations still treat SBOM generation as a one-time export rather than a continuous workflow — which is exactly where audits get flagged and incident response gets slower. This piece breaks down what an SPDX-based SBOM workflow actually requires, where established scanners like Black Duck stop short, and how Safeguard closes the gap between generating a document and proving compliance.
What is an SBOM, and why does it matter for compliance?
An SBOM (Software Bill of Materials) is a machine-readable inventory of every component, library, and dependency inside a piece of software, including transitive dependencies four or five layers deep. It matters for compliance because regulators and customers increasingly treat "we don't know what's in our software" as an unacceptable answer — the same way a food manufacturer can't ship a product without an ingredient list. The NTIA's July 2021 "Minimum Elements for a Software Bill of Materials" defines seven required data fields: supplier name, component name, version, unique identifiers (like a CPE or PURL), dependency relationships, author of the SBOM data, and timestamp. Two formats dominate: SPDX (originally an ISO/IEC 5962:2021 standard maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). SPDX 2.3, released in 2022, added explicit support for AI/ML model components and license expression fields — a direct response to auditors asking for more granular provenance data than version 2.2 could capture.
What does an SPDX-based SBOM workflow actually look like?
A working SPDX workflow has four stages: generation, validation, distribution, and continuous updates — and skipping any one of them is what turns a compliance checkbox into a liability. Generation happens at build time, ideally inside the CI/CD pipeline rather than as a post-release audit task, so the SBOM reflects the exact artifact that ships, not an approximation of it. Validation checks the SPDX document against the NTIA minimum elements and confirms license identifiers resolve to valid SPDX License List entries (the list currently tracks over 700 recognized licenses and exceptions). Distribution means making the SBOM available to customers or regulators in a queryable format — a PDF export doesn't satisfy most contractual SBOM clauses, which increasingly specify SPDX JSON or tag-value format. Continuous updates are the stage most tools miss entirely: when a new CVE is published against a component already in ten different SBOMs across five product lines, the workflow needs to flag every affected SBOM within hours, not at the next quarterly scan. A 2023 Synopsys-sponsored OSSRA report found that 84% of commercial codebases contained at least one known open-source vulnerability, which underscores why a static, point-in-time SBOM is nearly useless for ongoing compliance.
When are companies legally required to produce SBOMs?
Companies are legally or contractually required to produce SBOMs in a growing number of specific circumstances, starting with any federal software vendor covered by EO 14028 and OMB Memo M-22-18, which requires self-attestation of secure development practices backed by SBOM data for software sold to federal agencies. The FDA's premarket cybersecurity guidance, enforceable since October 2023 under the FD&C Act Section 524B, requires medical device manufacturers to submit an SBOM as part of premarket submissions for cyber devices. The EU Cyber Resilience Act, which entered into force in December 2024, will require SBOM-equivalent documentation for products with digital elements sold in the EU market, with core obligations phasing in through December 2027. PCI DSS 4.0, mandatory as of March 2025, doesn't name SBOMs explicitly but requires payment software vendors to maintain an inventory of software components — an obligation most QSAs now interpret as requiring SBOM-level detail. Beyond regulation, large enterprise customers increasingly write SBOM delivery into procurement contracts directly, meaning a vendor without a repeatable SBOM workflow can lose deals before a regulator ever gets involved.
How does Black Duck fit into (or fall short of) modern SBOM compliance workflows?
Black Duck (from Synopsys, now an independent company after its 2024 sale to Clearlake and Francisco Partners) is one of the most established tools for generating SBOMs and flagging open-source license risk, and many enterprises already have it deployed for exactly that purpose. Where teams run into friction is scope: Black Duck's core strength is composition analysis and license compliance, built on a signature-matching engine (Knowledge Base) designed years before SPDX 3.0 and today's CI/CD-native workflows became the norm. That means SBOM generation often runs as a scheduled or on-demand scan rather than a build-time artifact, which creates a gap between what shipped and what the SBOM describes — a gap auditors specifically look for during SOC 2 and FedRAMP assessments. It also tends to be licensed and priced around scan volume, which pushes teams toward scanning less often, running counter to the "continuous" requirement in NTIA and CISA guidance. None of this makes Black Duck a bad tool for what it was built to do; it means teams evaluating "SBOM compliance software" in 2026 are asking for build-integrated generation, automated re-validation on every new CVE disclosure, and audit-ready evidence trails — capabilities that sit outside Black Duck's original design center and that newer, developer-workflow-native platforms are purpose-built to cover.
What are the most common SBOM compliance failures auditors flag?
The most common failure auditors flag is an SBOM that's technically present but functionally stale — generated once at release and never updated as dependencies patch or new CVEs land against components already in production. Close behind is incomplete dependency depth: many generated SBOMs capture direct dependencies accurately but truncate or approximate transitive dependencies, which is exactly where high-severity issues like Log4Shell (CVE-2021-44228) hid in December 2021, buried four to six layers deep in dependency trees that most manual reviews never reached. A third recurring gap is missing or malformed license identifiers — SPDX requires either a valid SPDX License List identifier or a documented "NOASSERTION," and auditors treat blank or freeform license fields as a finding. Fourth, format fragmentation: organizations running SPDX for some products and CycloneDX for others, with no normalization layer, struggle to answer a simple customer question like "are we affected by CVE-2024-XXXXX across our whole portfolio" without manually cross-referencing multiple document formats. Finally, many teams can produce an SBOM on request but can't produce evidence of the SBOM generation and review process itself — which is specifically what SOC 2 Type II and FedRAMP assessors are testing for, since a document without a repeatable process behind it doesn't demonstrate a control.
How Safeguard Helps
Safeguard is built around the assumption that an SBOM is a living artifact tied to a specific build, not a document you generate once and file away. SBOM generation happens automatically inside the CI/CD pipeline in both SPDX 2.3 and CycloneDX formats, so the inventory always matches the artifact that actually ships — closing the drift gap that shows up in scheduled-scan tools. Every component is resolved to full transitive depth and matched against continuously updated CVE feeds, so when a new vulnerability like Log4Shell or a similar deeply-nested dependency issue is disclosed, Safeguard flags every affected SBOM across every product line within minutes, not at the next quarterly audit. License fields are validated against the SPDX License List automatically, and any component that resolves to NOASSERTION is surfaced as an open item rather than silently passed through. For teams under EO 14028, FDA premarket, EU CRA, or PCI DSS 4.0 obligations, Safeguard exports audit-ready evidence — generation timestamps, review history, and remediation tracking — so SOC 2 and FedRAMP assessors see a documented process, not just an output file. And because normalization runs underneath both major SBOM formats, a portfolio with mixed SPDX and CycloneDX history stays queryable from a single dashboard instead of requiring manual reconciliation. For teams evaluating tools already carrying Black Duck's license-compliance workload, Safeguard is designed to plug into the gaps around continuous validation and build-time accuracy without requiring a rip-and-replace of existing scanning investment. If your last SBOM export is more than one release cycle old, that's the workflow gap worth closing first.