SBOM Fields in Practice: What to Fill Beyond the NTIA Minimum Elements

Seven Elements Is a Floor, Not a Ceiling

Whenever the conversation turns to what an SBOM should actually contain, it tends to stall at the NTIA's seven minimum elements: supplier name, component name, version, unique identifier, dependency relationships, SBOM author, and timestamp. Check those seven boxes, and some teams consider the job done.

That assessment may have been defensible in the immediate aftermath of Executive Order EO 14028 in 2021. But the landscape has shifted considerably since then. The FDA began mandating complete SBOMs as part of medical device premarket submissions in March 2023. The EU CRA will apply in full by December 2027, carrying penalties of up to €15 million or 2.5% of global annual turnover. UN R155 / ISO 21434 and China's mandatory national standard GB 44495 are already in force across the automotive sector. Against that backdrop, the "minimum viable" framing of the seven elements grows increasingly awkward.

The problem isn't that the seven elements are wrong. It's that they are routinely filled out incorrectly in practice, and that a substantial number of fields determining real-world SBOM utility are left entirely unaddressed once the checklist is cleared. What follows works through those fields in order of priority—from required to strongly recommended—flagging the most common traps for engineers and compliance leads responsible for producing or consuming SBOMs.

---

Dissecting the Seven Elements: Where Teams Go Wrong

1. Supplier Name — The Most Ambiguous Field

This is the field most prone to misinterpretation in practice. A single component can carry multiple "supplier" identities: the original author, the downstream package maintainer, a mirror distributor, or an internal re-packager within the organization.

The classic mistake is entering a package registry name—such as npmjs.com—in the supplier field, or conflating a Git username with a legal entity. For internal forks or private mirrors, the supplier field must clearly reflect an internal identifier rather than copying the upstream name verbatim. Without that discipline, there is no fast path to answering "who actually owns this component?" during a vulnerability response event.

In SPDX (ISO/IEC 5962), the PackageSupplier field supports Organization: and Person: prefixes. CycloneDX—now an Ecma standard—draws a finer distinction between supplier and author. Whichever format you choose, align the semantics with downstream consumers before committing to a convention; parsing ambiguity compounds quickly at scale.

2. Component Version — "No Version" Is Not a Valid Reason to Leave It Blank

For internally built components that are compiled from source without a tagged release, leaving the version field empty breaks vulnerability matching entirely. The correct approach is to populate it with an abbreviated Git commit SHA—at least 12 characters—and document the version derivation method in a supplementary field.

3. Unique Identifier and Hash — Complementary, Not Interchangeable

A unique identifier (PURL or CPE) answers the question "which component is this?" A hash answers "which exact build artifact are we talking about?" Both are necessary, yet the two are frequently confused, or only one is provided.

The PURL (pkg: scheme) has become the de facto standard for cross-ecosystem interoperability, covering npm, Maven, PyPI, Cargo, and most other major package managers. CPE retains an irreplaceable role in government procurement contexts and NVD vulnerability matching.

Hash algorithm selection also matters. MD5 and SHA-1 are no longer adequate for integrity verification purposes; SHA-256 is the current minimum, and SHA-512 is appropriate for high-assurance environments. Equally important: clearly specify whether the hash covers the compressed archive or the unpacked file tree. Misalignment here guarantees verification failures on the consumer side. The distinction between snippet-level SCA and manifest-level SCA is directly relevant here—a manifest can only attest to a declared version, whereas a hash actually proves that the code in use matches what was declared.

4. Dependency Relationships — Shallow Graphs Are Barely Better Than None

Of all seven elements, dependency relationships are the most information-sparse and the easiest to handle superficially. Declaring only direct dependencies while omitting transitive ones sharply reduces vulnerability coverage. The broad blast radius of Log4Shell (CVE-2021-44228, December 2021) was in large part attributable to organizations having no visibility into how many layers of transitive dependencies had pulled log4j-core into their stacks.

Practical guidance:

• Expand transitive dependencies to at least three levels deep; for security-sensitive systems, full expansion is preferable.
• Distinguish relationship types—DYNAMIC_LINK, STATIC_LINK, CONTAINS—rather than collapsing everything into DEPENDS_ON.
• Development dependencies (devDependency) and runtime dependencies must be labeled separately; buyers have fundamentally different risk concerns for each category.

5. SBOM Author and Timestamp — The Starting Point of Lifecycle Management

The timestamp is not merely a record of when the SBOM was generated; it determines under what conditions the document should be treated as stale. Best practice is to populate both created (initial generation time) and a version identifier within documentNamespace, and to wire SBOM generation into the CI/CD pipeline so it refreshes automatically on every build—rather than being maintained as a one-time, manually updated artifact.

---

Beyond the Seven Elements: What Actually Determines Usability

Once the seven elements are in place, the following fields determine whether an SBOM can be machine-consumed, whether it can support vulnerability response, and whether it will satisfy audit requirements.

License Fields

SPDX License Expressions support compound expressions such as Apache-2.0 AND MIT. Both DeclaredLicense (what the package metadata claims) and ConcludedLicense (what scanning tools have actually confirmed) should be populated. When the two diverge, human review is required—automated overwriting is not acceptable. Practical methods for detecting license conflicts deserve their own deep dive.

Lifecycle Status and End-of-Life (EOL)

Python 2 reached EOL in 2020. AngularJS followed in 2022. Log4j 1.x stopped receiving maintenance as far back as 2015. Yet all of these components continue to appear in production SBOMs today, with no field indicating their EOL status. CycloneDX's lifecyclePhase field and custom properties can both carry this information, and it deserves to be treated as a required field. The risks posed by unmaintained open source components merit dedicated assessment.

VEX Linkage — Exploitability Context for Vulnerabilities

VEX (Vulnerability Exploitability eXchange) is not part of the SBOM specification itself, but it is tightly coupled to SBOM. An SBOM without an associated VEX document tells a consumer only that a component carries a given CVE—it provides no basis for judging whether that CVE is actually exploitable in the current deployment context.

VEX defines four core statuses—not_affected, affected, fixed, and under_investigation—which, combined with impact statements and action statements, form a complete and machine-readable vulnerability response chain. The EU CRA's reporting obligations (effective September 11, 2026) explicitly require manufacturers to provide exploitability assessments. VEX is currently the most mature machine-readable format for doing so.

Build Information and SLSA Provenance

How a component was built, by which pipeline, and whether that build is reproducible—these details carry decisive forensic value in supply chain compromise scenarios such as the xz backdoor disclosed in March 2024 (CVE-2024-3094). CycloneDX's externalReferences and buildMetaData fields, combined with SLSA provenance documents, represent the most actionable path to capturing this information today.

---

Producers and Consumers: Misaligned Priorities

The field priorities of SBOM producers (software vendors) and consumers (procurement teams, operators) are often substantially misaligned. If that misalignment isn't resolved at the contracting stage, it generates serious friction during vulnerability response.

Vendors tend to focus on:

• Whether fields satisfy regulatory submission requirements (FDA, CRA, GB 44495)
• Coverage rates and automation levels of their generation toolchains
• Whether sensitive internal information—proprietary component names, internal topology—needs to be redacted

Buyers tend to focus on:

• Whether hashes are verifiable (guarding against discrepancies between the SBOM and the actual deliverable)
• Whether transitive dependencies are fully expanded
• Whether VEX documents are updated continuously as new vulnerabilities are disclosed, rather than being attached once and never revised
• Whether EOL components are clearly flagged and accompanied by a remediation plan

Purchase contracts or technical annexes should explicitly specify: SBOM format version, update cadence, VEX response timelines, and agreed-upon conventions for disputed fields—supplier name and version in particular. The path from SBOM compliance requirement to organizational capability offers a more complete governance framework for reference.

For buyers receiving binary deliverables, SBOM declarations alone cannot verify actual composition. CleanBinary provides binary composition analysis that can validate SBOM accuracy from the artifact side. For teams that want to establish SBOM production standards during development, CleanSource SCA covers more than 600 package ecosystems and resolves dependencies against a corpus of 320 million component fingerprints, with native output in both SPDX and CycloneDX formats. Teams looking for a lighter starting point can use CleanSource SCA CE. PureStream addresses compliance governance with AI-driven policy orchestration, suited to organizations that need to enforce a consistent SBOM quality baseline across multiple teams.

---

Closing Thought: Field Quality Determines SBOM Value

An SBOM's value is not a function of how many fields it contains. It is a function of whether each field is accurate, machine-readable, and actively maintained throughout the component's lifecycle. An SBOM that checks all seven minimum elements but carries unverifiable hashes, a single-layer dependency graph, and inconsistent supplier names will offer very little when a vulnerability response is actually underway.

From the xz backdoor to the Shai-Hulud npm worm of September 2025, supply chain attack techniques continue to evolve. The quality of defensive information must keep pace with the complexity of the attack surface. Transforming SBOM from a one-time compliance document into a continuously updated software bill of materials requires field standards as a foundation, toolchain automation as the enabler, and clear contractual agreements between producers and consumers as the connective tissue.

For a comprehensive framework on building an SBOM program, see the Complete SBOM Guide. For medical device–specific compliance pathways, see Medical Device SBOM Compliance in Practice.

---