Add five ownership fields to every SBOM record: product, owning team, a named owner or contact group, environment or exposure, and criticality. These are not part of the SBOM standards. They are your own metadata, and they decide whether a finding reaches someone who can fix it.
Why the standard fields are not enough
The NTIA baseline lists supplier, component name, version, other identifiers, dependency relationship, author of the SBOM data and timestamp. They describe the components. They say nothing about who in your company is responsible for the product that contains them. When an advisory lands, the first question after "are we affected?" is "who do we tell?" A record with no owner turns that into a search through chat history.
The five fields
| Field | Example values | Used for |
|---|---|---|
| Product | Name and ID of the product or service | Grouping and customer answers |
| Owning team | Team name or group in your identity provider | Routing findings |
| Owner or contact | A group mailbox or on call alias, not one person | Escalation |
| Environment or exposure | Internet facing, internal, customer deployed, offline | Prioritisation |
| Criticality | A small scale you define, such as high, medium, low | Ordering work |
Use values from controlled lists. Free text creates five spellings of the same team within a quarter.
Where the data should come from
Do not ask people to type owners into a sheet each month. Pull them from a source that already exists: a service catalog, a repository ownership file, or your identity provider groups. The SBOM record then holds a reference and the catalog stays the single source of truth. When a team is renamed, one change flows everywhere.
If you must start manually, keep it small and put a review date on each row.
Keep the fields honest
- Owner by group, never by individual. People leave.
- Review quarterly. Export products with their owners and ask each owning team to confirm.
- Flag orphans. Any product with no owner appears on a list reviewed by the platform owner.
- Tie to release. A product can change hands between releases. Record the owner at the time of the release as well as today.
- Do not put sensitive notes in ownership fields. These fields may travel in exports.
Keep them out of external files
These are internal fields. When you export an SBOM for a customer, leave them out. The post on which SBOM fields can leak internal details explains the risk, and who owns SBOM and VEX requests covers the people side.
Using the fields
With ownership in place, you can route a new finding to the owning team automatically, report open findings by team, and rank by criticality and exposure. The SBOM governance guide shows where the fields fit into a wider process.
Spreadsheet or platform
In a sheet, ownership is a column that goes stale. In a platform, ownership can be a managed attribute linked to a catalog or identity groups, with a change log. That difference is one of the quieter reasons teams move.
Where Safeguard fits
Safeguard's asset discovery and inventory help you find what you own, and its SBOM and dependency scanning lists the components in it. Try the free scan at gold.safeguard.sh/scan.
Quick check
Are ownership fields part of SPDX or CycloneDX?
They are not part of the NTIA baseline. Treat them as your own metadata, kept in the platform or a catalog, and leave them out of external exports.
How many fields is too many?
If people skip them, you have too many. Five well kept fields beat fifteen stale ones.
Sources
Last reviewed: 19 October 2026.
