Auditors do not read SBOMs the way engineering teams produce them. Engineers ship the file, declare the box ticked, and move on. Auditors open the artefact, run a small battery of structural checks, sample a handful of components against ground truth, and form an opinion in under thirty minutes. The opinion almost never depends on whether the SBOM has 800 components or 2,400. It depends on whether the fields the auditor cares about are present, populated correctly, internally consistent, and verifiable against external sources. Most programmes that fail an SBOM review fail on three or four predictable fields, and those failures are entirely preventable if you know what gets checked. Drawing on a sample of 140 SBOM-driven audits we observed across SOC 2, ISO 27001, and FDA premarket review work in 2025-2026, this post lays out the fields that determine the verdict, the thresholds that distinguish "defensible" from "deficient", and the verification techniques you should run yourself before the auditor does.
Identifier Coverage: The First Filter
The first thing an auditor checks is whether components have stable, parseable identifiers. In CycloneDX that means purl. In SPDX that means a populated externalRefs block with purl or a CPE. The threshold that separates defensible from deficient programmes in our sample is a purl coverage above 95% across non-system components. Below 90% almost always triggers a finding.
The failure mode is silent. An emitter that cannot resolve a Maven coordinate to a purl falls back to a free-text component name. The SBOM looks complete to a casual reader and is unusable for cross-product queries. Auditors test this by sampling 20-30 components at random and checking whether each purl resolves. A single unresolvable purl does not fail the artefact; a 15% unresolvable rate fails the programme.
Run a self-test before submission: parse every purl, resolve against the public registry where possible, and report the percentage that round-trip cleanly. Anything under 95% is the first thing to fix.
Version Specificity And bom-ref Uniqueness
Versions matter more than people think. 2.x is not a version. 2.17 is not a version. 2.17.1 is a version. Auditors check that versions are specific enough to map to a CVE record, and they check that the same component does not appear with multiple inconsistent version strings.
bom-ref uniqueness is the structural twin. CycloneDX requires bom-ref values to be unique within a document; auditors will validate this with a schema check, and they will also verify that the dependency graph references resolve. A document with 2,000 components where 12 bom-ref values are duplicated is treated as broken even if the component data itself is accurate.
A reasonable internal threshold: 100% schema-valid, 100% bom-ref unique, and at least 98% of components with three-part semantic versions. Components where three-part versions genuinely do not exist (some firmware, some internal artefacts) should declare an explicit version policy in the SBOM metadata rather than producing a partial version.
Supplier And Author Population
Auditors care about who is asserting the SBOM and who supplied each component. The CycloneDX metadata.authors and per-component supplier fields are routinely empty in CI-emitted SBOMs, and that is a finding waiting to happen. SPDX has equivalents in creationInfo and Supplier.
Two thresholds matter. The metadata block must identify the producing organisation and a tool, ideally including a tool version (for example cdxgen 10.4.2). Per-component supplier population should be above 80% for components from public registries and 100% for first-party components. Components without a supplier are treated as unknown provenance, and "unknown provenance" propagates into vendor risk reviews months later.
Hashes, Signatures, And The Integrity Story
The single field that distinguishes a defensible programme from a "we generate SBOMs" programme is whether the artefact is signed. An unsigned SBOM is descriptive evidence; a signed SBOM with an in-toto attestation is verifiable evidence. Auditors increasingly treat unsigned SBOMs as advisory rather than authoritative.
Component-level hashes matter alongside artefact-level signatures. Each component should have at least one hash (SHA-256 is the de facto floor in 2026; SHA-512 for higher-assurance programmes), and the hash should match the artefact retrievable from the declared registry. Auditors test by pulling 5-10 components and comparing hashes; a mismatch on more than one is a finding.
Practical thresholds: 100% of artefacts signed, 100% of artefacts have a verifiable in-toto attestation, at least 90% of components have a SHA-256 hash, and 100% of those hashes match registry-published values for components whose registry is reachable.
Timestamps And Freshness
A correct SBOM that is six months old is wrong by today's vulnerability landscape. Auditors check metadata.timestamp and the implied freshness against the release version it claims to describe.
The threshold most programmes settle on: SBOM emission within 24 hours of the build it describes, and the SBOM document timestamp must fall inside the build window proven by the in-toto attestation. Drift between SBOM timestamp and build timestamp is a strong indicator of after-the-fact regeneration, which auditors flag.
For products under active development, the latest SBOM should never be older than the latest production release minus the deployment window. Programmes that fail this typically have a CI pipeline that emits SBOM only on tag push and miss hotfix releases entirely.
VEX Coverage And Vulnerability Stance
Auditors no longer treat raw vulnerability counts as evidence of weakness. They treat the absence of a published position on those vulnerabilities as evidence of an immature programme. A VEX coverage above 70% on the long tail of recurring "not affected" findings is a strong signal of programme maturity. Below 30% suggests the team is generating SBOMs but not operating on them.
Sample any product with a non-trivial vulnerability backlog. For each open critical or high, there should be either a remediation plan with a date or a VEX statement explaining why the issue is not exploitable in this configuration. Silence on a known critical is the worst possible answer.
Internal Consistency And Dependency Graph Sanity
The last battery of checks is structural. Does every component referenced in the dependency graph appear in the components list? Does the graph have orphans? Are there circular dependencies that should not exist? Are licences populated and drawn from the SPDX licence list rather than free-text variations of the same identifier (MIT, mit, MIT License)?
These are unglamorous checks, and they are the ones most CI emitters fail. Run a graph-walk validator before submission. A clean graph with normalised licence identifiers passes the structural battery in seconds; a noisy one consumes hours of auditor attention and almost always produces findings.
How Safeguard Helps
Safeguard runs the full auditor field battery on every ingested SBOM and AI-BOM, with a quality score that mirrors the thresholds in this post. SBOM ingest validates schemas, parses every purl, checks bom-ref uniqueness, verifies supplier and licence population, and flags hashes that do not match registry-published values. Signed attestation verification covers Sigstore, in-toto, and customer-managed key chains. VEX ingest measures coverage ratios across published CSAF 2.0 and CycloneDX VEX feeds and surfaces silence on known criticals as a programme-level finding rather than a component-level one. The platform makes the auditor's checks self-service, so the conversation with the assessor begins with a programme that is already in defensible shape.