One area that may benefit from clarification during implementation is
how the NTIA “Other Unique Identifiers” element and SBOM data handling
expectations are interpreted in practice.

For “Other Unique Identifiers,” many producers rely on internal or
system‑specific identifiers (e.g., build IDs, release IDs, or project
tracking identifiers) to support traceability across lifecycles, even
when those identifiers are not globally resolvable. These identifiers
often function as internal keys that enable correlation across SBOMs,
build systems, and vulnerability tracking, rather than as public package
identifiers. It may be helpful to ensure the conformance checker accepts
such internal identifiers when they serve a traceability purpose
consistent with NTIA guidance, rather than assuming all identifiers must
be externally resolvable or standardized.

Relatedly, SBOM data is frequently subject to internal data
classification and handling policies. While classification itself is not
an NTIA minimum element, organizations commonly treat SBOMs as artifacts
that may contain sensitive supply‑chain or dependency information and
apply classification and access controls accordingly. This can influence
which fields are included, redacted, or shared at different lifecycle
stages.

From an implementation perspective, it may be useful to distinguish
between core conformance requirements and contextual metadata (such as
internal identifiers or data‑handling considerations) so that valid
SBOMs are not marked non‑conformant due to normal enterprise governance
practices.

Add 2025 CISA Minimum Elements #305

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions