CBOM validation: completeness and accuracy checks

A CBOM that parses is not necessarily a CBOM you can trust. Validation has layers: format, required fields, internal consistency, agreement with reality and coverage of the estate.

Why validate

CERT-In's Version 2.0 guidelines recommend "periodic audits and assessments of the CBOM/QBOM ... to verify completeness, accuracy, and compliance" (rec. 8.4.1.10) ^[1]. Validation also matters for decisions: a CBOM that omits half the TLS endpoints will under-report weak protocols, and one with wrong key sizes will send remediation effort to the wrong places. Treat validation as a gate that each CBOM passes before it is published or accepted from a supplier.

Layer 1: format

Check that the document is valid against the schema of the CycloneDX version it declares. The CycloneDX CLI provides a validate command, along with diff, merge and convert, and can verify signed BOMs ^[2]. Common failures include values outside enumerations, for example, a primitive that is not one of the schema's values such as block-cipher, signature, hash or kemand dates that do not use the schema's date-time format ^[3].

Layer 2: required fields

Schema validity says little about content, because most CycloneDX fields are optional. Apply a field policy per asset type. CERT-In's Table 9 gives a baseline ^[1]:

The CycloneDX mappings follow the property names in the 1.6 schema ^[3]. Report missing fields per asset, not just a pass or fail for the document, so that producers know what to fix.

Layer 3: internal consistency

• Reference integrity. Every signatureAlgorithmRef, subjectPublicKeyRef and algorithmRef should resolve to an asset in the same BOM ^[3].
• Plausible values. A certificate's Not Valid Before should precede Not Valid After; a key's activation date should not precede its creation date; the classical security level should match the algorithm and size.
• Valid states. Key states should be one of the lifecycle states, and consistent with dates, a key marked active past its expiration date deserves a question. The schema's six key states match those defined in NIST SP 800-57 Part 1 ^[6].
• No duplicates. The same certificate fingerprint or key identifier should appear once, referenced where it is used.

Layer 4: accuracy against reality

Compare the CBOM with independent evidence:

• Live endpoints. Re-scan a sample of TLS endpoints with testssl.sh or SSLyze and compare protocols, cipher suites and certificates with what the CBOM claims ^{[4] [5]}.
• Key stores. Reconcile key assets with HSM and KMS exports by key identifier.
• SBOM. If the SBOM lists a cryptographic library, the CBOM should contain the algorithms that library provides to the application, or explain why not.
• Policy results. A CBOM that shows no deprecated algorithms at all in a large legacy estate may be incomplete rather than clean; spot-check against known baselines such as NIST SP 800-131A Rev. 2 ^[7].

Layer 5: coverage and freshness

• Coverage. Compare the applications, hosts and products with a CBOM against the asset register. Uncovered items are gaps, not zero-risk.
• Freshness. Check the metadata timestamp. CERT-In recommends scheduled reviews "at least quarterly" ^[1].
• Authorship. Record which tool or supplier produced each CBOM so quality issues can be traced.

Validating supplier CBOMs

Apply the same layers to CBOMs you receive, and write the required field policy into contracts so that suppliers can validate before delivery. Reject or return CBOMs that fail format or required-field checks; raise accuracy discrepancies as findings with the supplier. See CBOM procurement requirements.

How IntelliXBOM helps

IntelliXBOM validates CBOMs against required-field policies such as CERT-In's minimum elements and reports which assets are missing which fields. Version history and diffs show what changed between submissions, and correlation with vulnerabilities, end-of-life data and business services helps teams confirm that the inventory reflects what is deployed.