A layered acceptance model

LayerTestExpected result
1 · Parse and schemaUse the exact declared schema/versionInvalid paths and rules are identified.
2 · MetadataCheck product, version, context, timestamp and generating toolThe artifact can be assigned to the intended release.
3 · IdentityResolve identifiers and inspect versionsAmbiguous or unresolved components remain visible.
4 · GraphCheck references, edges, roots and duplicatesEvery edge points to an existing node or documented external reference.
5 · CoverageCompare with independent build and artifact evidenceMissing expected components are reported.
6 · Integrity and provenanceVerify signature and delivery origin where applicableTampering and untrusted authors are detected.

Source: CycloneDX · 1.7 JSON reference.

Schema validity is a format property. Coverage is a claim about the software and the discovery process. Keep separate results and severities so one cannot conceal the other.

Create passing and failing fixtures

  1. Create a representative passing file with known direct and transitive components.
  2. Remove a required field and expect a schema failure with an exact location.
  3. Insert a relationship pointing to a nonexistent node and expect a graph failure.
  4. Remove a known vendored component while keeping the document schema-valid; expect a coverage failure.
  5. Change the product version and expect a release-binding mismatch.
  6. Duplicate a component under inconsistent identifiers and expect an investigation finding.
  7. Tamper with a signed artifact and expect integrity verification to fail.

The fourth test is the important counterexample: a valid document can still omit software. Keep the reference evidence with the fixture so a vendor cannot explain the omission away by redefining scope during the demo.

Check component identity without destroying evidence

Validate PURL syntax and ecosystem meaning. Preserve namespace, qualifiers and distribution context where they matter. A binary hash is meaningful only when you know which artifact was hashed and with what algorithm. Do not normalize a fork into its upstream project just because they share a package name.

Distinguish a genuinely absent version from an unrecognized format. Track aliases and manual overrides with the original value, the resolver version, evidence, approver and date. Re-run affected matches when the identity rule changes.

Inspect graph and completeness

Find isolated nodes, missing roots, cycles and external references. These findings need interpretation: a shared dependency is legitimate, and an isolated component may represent a different relationship class. Rejecting every unusual graph can discard useful supplier evidence.

Compare against lockfiles, resolved package reports, packaging manifests and delivered-artifact scans. Investigate statically linked code, nested archives, base-image packages and proprietary modules separately. Record known unknowns and redactions so downstream users can assess confidence.

Do not claim “100% complete” from a larger component count. Define coverage relative to a declared artifact, observation method and reference set.

Route failures to accountable owners

FindingSuggested handling
Unparseable or unsafe inputQuarantine; preserve original; request correction.
Wrong product or releaseBlock association with production assets.
Unknown component versionAccept only under a recorded exception where the use case permits.
Missing expected critical componentBlock the quality gate or escalate a time-bound exception.
Unsupported optional fieldRetain original and disclose the normalization loss.
Unverified signatureRecord trust status; apply the agreed receiving policy.

These severities are buyer recommendations, not regulatory categories. Align them with your product risk and obligations. Use a limited parser environment for supplier files; file-size, decompression and external-reference restrictions belong in intake design.

Make quality repeatable

Store the validator version, rule profile, timestamp, artifact hash and result with each inventory. Preserve prior findings when a correction arrives. A clean dashboard is less useful than a reproducible explanation of why an artifact was accepted.

Before production, rehearse a correction: supplier resubmits, ingestion identifies the predecessor, affected vulnerability findings are reevaluated, and the original evidence remains available. Include this workflow in procurement acceptance.

Primary sources