AA-sec logo AA-sec
SBOM

SBOM Quality: Completeness, Accuracy, and Release Traceability

A practical guide to improving SBOM quality through explicit completeness, reliable component identity, dependency accuracy, release binding, validation, and retained evidence.

AA-sec22 August 2026
  • release-specific SBOM quality
  • SBOM completeness
  • SBOM accuracy
  • SBOM validation
  • release SBOM traceability
  • release-specific SBOM
Cover graphic showing an SBOM linked to component identities, dependency relationships and a specific software release.

SBOM quality is the difference between having a machine-readable component list and having a software bill of materials that can reliably support vulnerability analysis, release decisions and lifecycle evidence. A syntactically valid SBOM may still be weak if component identities are ambiguous, dependency relationships are missing, completeness is unknown, or the file cannot be tied to the exact software release it describes.

For product teams, a useful quality model has four parts: completeness, accuracy, relationship quality and release traceability. Those dimensions should be validated separately. A large SBOM is not automatically complete, and a schema-valid SBOM is not automatically accurate.

The Cyber Resilience Act (CRA) establishes a legal minimum rather than a universal quality score. Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the product's top-level dependencies. Operationally, teams often need richer data than that minimum to investigate transitive dependencies, match vulnerabilities, compare releases and explain what changed.

Start with the exact subject of the SBOM

Before checking individual components, define what the SBOM represents. A quality review is difficult if the subject is only a project name such as backend or device-firmware with no release context.

Record enough information to distinguish the subject from every other build or release that may exist. Depending on the product and build system, useful identifiers can include:

  • product and variant;
  • version or release identifier;
  • package, container, firmware or artifact name;
  • immutable artifact hash where available;
  • build identifier or build provenance reference;
  • generation timestamp;
  • SBOM format and specification version; and
  • generator name and version.

The goal is not to maximise metadata. It is to make one question answerable later: which exact software did this SBOM describe?

A source-tree SBOM and an SBOM generated from the final release artifact can legitimately differ. BSI TR-03183 Part 2 distinguishes SBOM types according to when and how they are generated, including design, source and build perspectives. SPDX 3.0.1 likewise defines SBOM types such as source, build, analyzed, deployed and runtime. Treat the generation perspective as part of the SBOM's scope rather than assuming that every tool sees the same software.

Completeness has more than one dimension

Teams often ask whether an SBOM is "complete" as if completeness were a single percentage. In practice, at least two separate questions matter.

Inventory completeness asks whether the relevant components are represented. This includes deciding what the SBOM is expected to cover: first-party modules, direct third-party packages, transitive dependencies, embedded components, generated code, bundled runtimes, container base layers, plugins or other software delivered with the release.

Relationship completeness asks whether the connections between those components are known. A component can appear in the inventory while its dependency path is missing or uncertain. That matters because vulnerability analysis often needs to answer not only whether a component exists, but also where it is used and which product or higher-level component depends on it.

CycloneDX provides compositions that can state whether an inventory or set of dependency relationships is complete, incomplete or unknown. Its dependency guidance also warns that a component omitted from the dependency graph should not automatically be interpreted as dependency-free; its dependencies may simply be unknown.

SPDX 3.0.1 provides a similar distinction for relationships. Its RelationshipCompleteness vocabulary can express that a relationship is complete, incomplete or that no assertion is made. These mechanisms are useful because known uncertainty is better data than false certainty.

Define completeness against a declared scope

A useful completeness statement needs a boundary. "Complete SBOM" is too broad if nobody knows whether it means all packages resolved by the package manager, everything linked into a binary, all software in a container image, or all software observable at runtime.

For each SBOM generation method, document:

  • the input or artifact being analysed;
  • which ecosystems and package types the generator can detect;
  • whether direct and transitive dependencies are expected;
  • whether statically linked or vendored components are covered;
  • whether generated, embedded or dynamically loaded software is covered;
  • known exclusions and unsupported ecosystems; and
  • whether completeness is asserted, known to be partial, or unknown.

This turns completeness from a vague aspiration into a testable statement. It also makes comparisons between tools more meaningful. Two generators can produce different component counts because they observe different lifecycle stages or use different detection methods, not necessarily because one is wrong.

Accuracy depends on reliable component identity

A component entry is useful only if downstream systems can identify what it refers to. Ambiguous names such as common, utils or openssl without sufficient version and supplier context can create false matches or missed matches during vulnerability analysis.

For each component, validate the strongest identifiers available for that ecosystem. These may include:

  • canonical package name and version;
  • supplier or namespace information where relevant;
  • Package URL (PURL);
  • CPE where it is appropriate and reliably assigned;
  • cryptographic hashes for artifacts or files where useful;
  • unique internal identifiers for first-party components; and
  • stable references used by the SBOM's dependency graph.

CycloneDX uses bom-ref to cross-reference components and dependency relationships within a BOM and recommends identifiers that remain unique and readable, such as PURL where suitable. SPDX provides a broader data model for composition, provenance, integrity and relationships. Whichever format is used, the quality objective is the same: the identity used by vulnerability tooling should refer to the same component that engineering actually shipped.

Avoid silently "repairing" uncertain identity during ingestion. If a package name or version cannot be established confidently, retain that uncertainty and create a review path. A guessed version can be more damaging than a visible missing field because it can produce convincing but incorrect vulnerability results.

Bind the SBOM to the release, not just the repository

Release traceability is what makes historical SBOMs useful after the codebase has moved on. A vulnerability disclosed six months later must be assessed against the components that were actually present in the affected release, not against today's dependency file.

A practical release binding can include:

  • the product and variant identifier;
  • released version;
  • immutable artifact digest or equivalent identifier;
  • build or pipeline execution identifier;
  • source revision where relevant;
  • SBOM file digest;
  • generation tool and version; and
  • the time and lifecycle stage at which the SBOM was produced.

SPDX's build profile can describe build inputs, outputs and tools, while CycloneDX supports dependency, composition and formulation information. You do not need to populate every available field to obtain traceability, but the relationship between the released artifact and its SBOM should be unambiguous and durable.

Do not overwrite an old SBOM when a new release is produced. Keep the release-specific file and its identity so later investigations can reconstruct which components and dependency relationships were known at that point in time.

Validate more than the schema

Schema validation is necessary because malformed data is difficult to exchange, but it is only the first quality gate. A practical SBOM validation pipeline should use several layers.

1. Syntax and specification validation

Check that the document parses and conforms to the declared CycloneDX or SPDX version. Reject malformed identifiers, invalid enumerations and structural errors that make the SBOM unreliable for automated consumers.

2. Subject validation

Confirm that the SBOM identifies the expected product, artifact and release. A perfectly valid SBOM for yesterday's build is still the wrong SBOM for today's release.

3. Identity validation

Flag missing or contradictory versions, duplicate component identities, impossible package coordinates, unresolved placeholders and identifiers that cannot be used reliably by downstream vulnerability tooling.

4. Inventory and graph validation

Check whether expected direct dependencies appear, whether graph references resolve to known components, whether obvious orphaned relationships exist, and whether unknown or partial coverage is declared rather than hidden.

5. Release consistency validation

Compare the SBOM with other release evidence. Depending on the environment, this may include lockfiles, package manifests, container layers, firmware package lists, linker output, build provenance or an independently generated artifact scan.

The objective is not to force every source to produce an identical list. Differences should be explainable. An unexplained missing component is a quality finding; a documented difference caused by generation perspective is context.

Use differences between releases as a quality signal

An SBOM becomes more useful when teams compare it with the previous approved release instead of reviewing each file in isolation.

Useful changes to surface include:

  • components added or removed;
  • component version changes;
  • new or removed dependency relationships;
  • changes from complete to incomplete or unknown coverage;
  • changes in supplier or package identity;
  • newly unresolved component metadata; and
  • unexpected reductions in component count or graph coverage.

A large reduction in components may be a legitimate architectural improvement, but it should be explainable. The same applies when a dependency disappears from the graph without disappearing from the inventory. Diff review helps distinguish expected engineering changes from generator regressions or pipeline failures.

For automated pipelines, make the gate proportional. A changed SBOM should not fail a release merely because it changed; it should fail or require review when defined quality expectations are violated or when a material unexplained difference remains unresolved.

SBOM quality directly affects vulnerability handling

BSI TR-03183 Part 2 describes SBOMs as important inputs to continuous security and lifecycle management. It also makes an important boundary clear: an SBOM can help identify whether a product may contain a component associated with a vulnerability, but the SBOM itself does not determine whether that vulnerability is exploitable in the product.

That distinction is operationally important. A precise component identity improves vulnerability matching. A reliable dependency graph helps locate where the component is used. Release traceability shows which shipped versions may be affected. Engineering still has to analyse the product context and make the vulnerability-impact decision.

Poor SBOM quality creates noise in both directions. Missing components can hide candidates that deserve review, while weak identities can produce false matches that consume triage time. Quality therefore belongs upstream of vulnerability scanning, not only inside the scanner.

ENISA's 2026 SBOM adoption report describes organisations investing in SBOM generation and automation as part of the software development lifecycle in response to the CRA. Automation is useful only when the resulting data is measurable and reviewable; generating a file on every build is not a substitute for knowing whether the file describes the build accurately.

Practical release acceptance criteria

A team can turn the quality model into a small set of release checks. Adjust the exact threshold to the product and tooling, but make the rules explicit.

Before accepting a release SBOM, confirm that:

  • the document passes format and schema validation;
  • the subject identifies the expected product, variant and release;
  • the SBOM can be tied to the released artifact or build;
  • component references are unique and internally consistent;
  • required component identities are present for supported ecosystems;
  • dependency references resolve correctly;
  • inventory and relationship coverage are declared where the format supports it;
  • known generator limitations and exclusions are recorded;
  • unresolved placeholders or ambiguous versions are reviewed;
  • material changes from the previous release are explained; and
  • the SBOM file, its digest and validation result are retained with the release evidence.

These checks do not prove that every hidden or dynamically introduced component has been found. They establish whether the organisation can explain the SBOM's scope, quality and relationship to the release.

Retain the evidence behind the SBOM

For important releases, retain more than the generated file. Useful supporting evidence includes:

  • the SBOM and its cryptographic digest;
  • generator name and version;
  • declared SBOM format and version;
  • generation perspective or lifecycle stage;
  • source, build or artifact identifiers used as inputs;
  • validation results and quality findings;
  • documented exclusions or accepted limitations;
  • reviewer decisions for material exceptions; and
  • previous release SBOMs needed for historical comparison.

This evidence makes later questions much easier to answer: whether a component was present, when it entered the product, which release first contained it, what the generator could see, and whether a gap was known when the release was approved.

A high-quality SBOM only stays useful if its component data remains connected to the exact product and release it describes. AA-sec is designed around traceability between SBOM and component data, vulnerability work, security evidence and lifecycle decisions, so teams can keep that context attached as products change. AA-sec does not determine CRA conformity or replace the manufacturer's engineering judgement about SBOM scope, completeness or release acceptance.

Key takeaway

Treat SBOM quality as an evidence problem, not a file-size problem. Validate the subject, component identities, inventory coverage, dependency relationships and release binding separately, and preserve uncertainty where the available data is incomplete.

CycloneDX and SPDX both provide mechanisms for richer identity, relationship and completeness context. BSI guidance and ENISA's 2026 adoption work reinforce the operational direction: SBOMs are most valuable when they are integrated into lifecycle and vulnerability-management processes rather than generated as isolated compliance artifacts.

For CRA readiness, the legal minimum is a starting boundary. The stronger engineering objective is an SBOM that can still answer reliable questions about a specific shipped release when a vulnerability appears months or years later.

Official sources