A software bill of materials (SBOM) is a machine-readable inventory of the components, and their relationships, that make up a piece of software. It has moved from a nice-to-have to a compliance requirement because regulators and buyers concluded that you cannot manage supply-chain risk in software you cannot enumerate. The baseline expectation in the United States is the NTIA minimum elements; the EU Cyber Resilience Act adds its own SBOM duty; and sectors such as medical devices now require SBOMs in regulatory submissions. This FAQ answers the questions teams ask most about SBOM compliance, and notes Safeguard's own posture honestly: our platform is architected for FedRAMP HIGH and DoD Impact Level deployment, and our SOC 2 Type II audit is in progress.
Frequently Asked Questions
Why has an SBOM become a compliance requirement? Executive Order 14028 made SBOMs a cornerstone of US software supply-chain policy, and subsequent guidance, sector regulations, and the EU Cyber Resilience Act turned the expectation into concrete obligations. The logic is simple: incidents like Log4Shell showed that organizations could not answer "are we affected?" quickly because they did not know what components they shipped. An SBOM is the inventory that makes that question answerable in minutes. Safeguard's SBOM Studio generates that inventory automatically at build time so it is always current.
What are the NTIA minimum elements? The NTIA minimum elements, published in 2021, define three categories: required data fields, automation support, and practices and processes. The data fields are supplier name, component name, component version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. The automation and practice categories require a machine-readable format and defined processes for frequency, depth, and handling of "known unknowns."
Which SBOM formats are accepted? The three widely recognized machine-readable formats are SPDX, CycloneDX, and SWID tags. SPDX is an ISO standard (ISO/IEC 5962) maintained by the Linux Foundation; CycloneDX is an OWASP format that was also standardized as Ecma-424; and SWID tags follow ISO/IEC 19770-2. US guidance is format-agnostic among these, so choosing one is largely about tooling fit rather than regulatory preference.
Is there updated minimum-elements guidance? CISA has continued to steward SBOM policy and, in 2025, published a draft update to the minimum elements for public comment, proposing refinements such as additional fields and clearer generation-context expectations. As of 2026 you should track that work but treat the 2021 NTIA elements as the operative baseline until a final version supersedes them. Building your SBOM process to exceed the current minimum is the safe hedge against the update.
Where are SBOMs actually mandated? Several places converge. Software producers selling to US federal agencies attest to secure development practices that include component tracking; the EU Cyber Resilience Act requires an SBOM covering at least top-level dependencies; and the FDA requires SBOMs in premarket submissions for cyber devices. Add customer contracts and security questionnaires, and most vendors of any scale now face an SBOM requirement from at least one direction.
Does the FDA require SBOMs for medical devices? Yes. Under section 524B of the Federal Food, Drug, and Cosmetic Act, premarket submissions for "cyber devices" must include a software bill of materials covering commercial, open-source, and off-the-shelf components. The FDA has authority to refuse submissions that lack the required cybersecurity information. If you build connected medical devices, the SBOM is part of getting to market, not an afterthought.
How deep does an SBOM need to go? The NTIA baseline expects at least the direct, first-order dependencies, but best practice and increasing regulatory pressure push toward transitive dependencies as well, because that is where most hidden risk lives. Where you cannot fully enumerate a subtree, you must flag those "known unknowns" rather than pretend completeness. Build-time generation is what makes deep, accurate dependency graphs feasible.
What is VEX and do I need it alongside an SBOM? VEX (Vulnerability Exploitability eXchange) is a companion artifact that states whether a product is actually affected by a given vulnerability, using statuses such as not affected, affected, fixed, or under investigation. It matters because an SBOM plus a naive vulnerability lookup produces enormous noise, most of which is unreachable in your product. Safeguard pairs SBOMs with continuous software composition analysis and VEX-style exploitability context so you report real risk rather than raw CVE counts.
How should SBOMs be generated? The most accurate SBOMs are generated at build time, when the toolchain knows exactly which versions were resolved and linked. Source-based generation can miss build-time resolution, and binary-based generation is useful for third-party artifacts but is inherently less precise. Whichever method you use, the generation context should be recorded so consumers know how the SBOM was produced.
How often must an SBOM be updated? An SBOM should be regenerated whenever the software changes — every build or release — because a stale SBOM describes software you no longer ship. The NTIA practices explicitly call for defining generation frequency, and tying it to your release pipeline is the reliable answer. Manual, periodic SBOM creation drifts out of date almost immediately in an active codebase.
Do I have to publish my SBOM publicly? Generally no. Most regimes require that an SBOM exist and be made available to the right parties — regulators on request, or customers under contract — not that it be posted publicly. The CRA, for instance, requires the SBOM to be documented and available to authorities, not published. Access control and controlled distribution are legitimate parts of an SBOM program.
Which format should I choose? For security and vulnerability-management workflows, CycloneDX tends to fit best because of its strong VEX integration; for license-heavy and legal-review contexts, SPDX is often preferred. Since generating both at build time is cheap, many teams emit both and treat one as canonical. The regulatory guidance does not force the choice, so let your downstream tooling decide.
How does Safeguard help meet SBOM requirements? Safeguard generates machine-readable SBOMs in both CycloneDX and SPDX at build time, keeps them version-controlled, and enriches them with continuous vulnerability and exploitability evidence so they satisfy both the inventory and the risk-management sides of compliance. The compliance workspace organizes these artifacts into exportable evidence packs mapped to the relevant frameworks.
For more, compare Safeguard against other SBOM and SCA tools on the comparison page, and read the full product documentation at docs.safeguard.sh.