Safeguard
Software Supply Chain•

SBOM management for regulated industries: what good looks like

Regulated teams need SBOMs that are current, per release, tied to vulnerability data and kept as evidence. Start from CISA 2026 minimum elements.

Safeguard Security Team
4 min read

SBOM management in a regulated industry means more than generating a file. You need a software bill of materials for every release, stored with the build, matched continuously against new vulnerability data, and available to customers and regulators on request. The baseline is now CISA's 2026 Minimum Elements, which replaced the 2021 NTIA version.

What changed in the baseline?

In 2021 NTIA published the original Minimum Elements for an SBOM, in response to Executive Order 14028. On 29 July 2026, CISA, the NSA, the FBI and international partners released joint guidance, 2026 Minimum Elements for a Software Bill of Materials, which CISA says updates and replaces the NTIA document. CISA says the new guidance reflects feedback from a 2025 public comment period and current tooling, and notes that some software types, such as artificial intelligence and software as a service, may need additional elements. Read the PDF itself for the exact data fields before you build to it.

Regulation is also moving. The EU Cyber Resilience Act entered into force on 10 December 2024. According to the European Commission, reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027, and the Commission published practical guidance for manufacturers on 27 July 2026. If you sell products with digital elements into the EU, plan for it.

What does "good" look like?

One SBOM per release, not per quarter. An SBOM describes a specific build. Generate it in the pipeline, attach it to the artifact, and keep it for as long as you support that release.

Complete, including transitive dependencies. The direct dependency list is the easy part. The risk sits in what those dependencies pull in.

Machine readable and standard. Use a recognized format such as SPDX or CycloneDX so customers and tools can read it.

Connected to vulnerability data. An SBOM is an inventory. Its value comes from matching it against advisories continuously, since new flaws are published after you ship. CISA also describes VEX, the Vulnerability Exploitability eXchange, as an attestation that says whether a product is affected by a known vulnerability. Pair the two so customers do not have to guess.

Governed. Know who generates, approves, stores and shares SBOMs, and who may see them. Some customers ask for them under confidentiality.

Verified. Validate documents against the format specification before you publish.

What do regulated buyers and auditors ask?

  • Can you produce an SBOM for the exact version we run?
  • How fast can you tell us whether a new vulnerability affects us?
  • How do you handle components with no fix?
  • Where are SBOMs stored, and how long are they kept?
  • Do suppliers give you SBOMs for what you embed?

Answer with artifacts. A dated SBOM and a VEX statement beat a policy document.

Honest limits

An SBOM does not prove a component is safe, only that it is present. Generators can miss components in unusual build setups, and different tools can produce different lists for the same project. Compare outputs on a sample before relying on one, and treat gaps as findings.

Try it

See how a dependency inventory is built in our interactive demo.

Open the full version at /demos/sca-dependency-inventory.

What to do

  1. Read the 2026 Minimum Elements and list which fields your current SBOMs lack.
  2. Generate an SBOM in CI for every release and attach it to the artifact.
  3. Validate each document against SPDX or CycloneDX before publishing.
  4. Match SBOMs against vulnerability data daily and route matches to owners.
  5. Issue VEX statements for flaws that do not affect a product.
  6. Require SBOMs from suppliers of embedded components and store them.
  7. Define retention, access and sharing rules, and test your response to a customer request.

Quick check

Is an SBOM legally required for everyone?

No single rule covers everyone. Requirements depend on your sector, customers and markets. US federal procurement and the EU Cyber Resilience Act are two drivers. Ask counsel what applies.

Do I need to publish my SBOM publicly?

Not necessarily. Many organizations share them with customers on request, under agreement. Decide by customer need and risk.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.