SBOM governance means deciding, in writing, who asks for software bills of materials, how often they are produced, how deep they go, where they are stored, who may see them and who reviews the content. The NTIA minimum elements already list these as practices and processes to define.
What the minimum elements say
The NTIA report on minimum elements for an SBOM, dated July 12, 2021, groups them in three areas.
- Data fields: supplier, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp.
- Automation support: machine-readable formats that can be generated and consumed automatically. The report names SPDX, CycloneDX and SWID tags.
- Practices and processes: frequency, depth, known unknowns, distribution and delivery, access control, and accommodation of mistakes.
The first two are mostly technical. The third is governance, and it is where programs stall.
Six decisions to write down
| Practice | Decision for your organization |
|---|---|
| Frequency | A new SBOM whenever a component is updated with a new build or release. Who triggers it? |
| Depth | How many levels of transitive dependencies must be listed? Define it by steps or by operational terms |
| Known unknowns | If the dependency graph is incomplete, the author states that explicitly. Who checks the statement? |
| Distribution and delivery | Where do SBOMs live, and how do customers or internal teams get them? |
| Access control | Who may see them? Internal use, customers under agreement, or public? |
| Accommodation of mistakes | How do you correct an SBOM and tell people about the fix? |
Roles to assign
- Producer: the team that builds the software generates the SBOM in the pipeline.
- Steward: a central owner who sets format, depth and storage standards.
- Consumer: security, legal and procurement who use SBOMs for vulnerability, license and supplier questions.
- Approver for external sharing: typically legal and product security.
Reviewing what you produce
Generating an SBOM is not the same as reviewing it. Sample a few each quarter. Do the versions match what is deployed? Are unique identifiers present? Is the dependency relationship recorded? Do the entries cover the build artifacts customers receive? Record results and fix generation settings, not individual files.
For inbound SBOMs from suppliers, decide the minimum you will accept and what you do with a gap. A supplier SBOM that omits dependency relationships can still help, but note the limits.
Policy wording that works
Keep it short. For example: each production release has a machine-readable SBOM generated by the build, stored in the central repository, available to named internal roles, and shared externally solely after approval. Corrections are published as a new revision. See correcting a mistake in a shared SBOM for the revision side.
Try it yourself
Click through it at your own pace, or open it full screen. Check which data fields you can see for each component.
Safeguard's SBOM and dependency scanning generates inventories, and its compliance and evidence automation helps keep the records that show when and how they were produced. A free scan lets you look at the output for your own project.
Quick check
Are the NTIA minimum elements a legal standard?
They are a report describing a baseline. Whether a customer or regulator references them depends on your situation, so check your obligations.
Should SBOMs be public?
That is a business decision. Many organizations share under agreement. Decide access control in advance.
Sources
Last reviewed: 19 October 2026.
