CBOM JSON response

JSON structure

Fields that have no value are omitted entirely; they are never returned as null, "" or []. Treat an absent key as "not known", not as "empty".

"cbom_info": {

"final_verdict": { //scan-level summary; advisory only

"verdict": "<string>",

//"Verification Failed" | "No Cryptography Found" | "Unsafe Cryptography Found" | "Safe Cryptography Found"

"verdict_explanation": ["<string>"], //one entry, equal to "verdict"

"blocked": false, //always false: CBOM never blocks a file

"severity": "INFO", //always "INFO"

"total_asset_count": "<int>", //number of entries in "components"

"asset_counts": { //assets per type

"algorithm": "<int>",

"certificate": "<int>",

"protocol": "<int>",

"related_crypto_material": "<int>",

"library": "<int>"

"risk_summary": {

"overall": { "safe": "<int>", "unsafe": "<int>" }, //safe + unsafe = total_asset_count

Type-specific properties

Each component carries one *_properties object inside crypto_properties, selected by asset_type:

`asset_type`	Object	Fields
`algorithm`	`algorithm_properties`	`algorithm_family`, `parameter_set_identifier`, `category`, `key_lengths[]`, `classical_security_level`, `nist_quantum_security_level`, `output_size`, `reference_primitive`, `performance`, `usage.recommended`
`certificate`	`certificate_properties`	`subject_name`, `issuer_name`, `certificate_format`, `description`, `not_valid_before`, `not_valid_after`, `public_key_length`, `signature_algorithm_ref`, `public_key_algorithm_ref`, `signature_algorithm_details`, `public_key_algorithm_details`
`protocol`	`protocol_properties`	`type`, `version`, `cipher_suites[]`, `usage.recommended`
`related_crypto_material`	`related_crypto_material_properties`	`type`, `algorithm_ref`, `key_lengths[]`, `min_key_length`
`library`	(none)	Library details are at the `crypto_properties` level: `vendor`, `library_type`, `library_supports[]`, `notes[]`, `detection_kind`

For certificates, signature_algorithm_details and public_key_algorithm_details are full algorithm objects, each with its own risk block. A certificate takes the weaker of its two algorithms' risk on each axis, so these objects explain why it was graded as it was. public_key_algorithm_details.detected_key_length is the key length measured from the certificate itself.

For libraries, detection_kind tells how the library was found: declared-dependency (named in a package manifest) or link-flag (only linked in a build script, so no version or package identity is available).

Field notes

Risk

overall_safe is what the UI shows as Overall Risk: true is Safe, false is Unsafe. An asset with an unknown level on either axis counts as unsafe.
quantum.is_pqc names a mechanism and is distinct from the quantum-safe level: AES-256 is quantum-safe without being a post-quantum algorithm.
quantum.recommended_replacement is an array, because there can be more than one successor. RSA, for example, needs ML-KEM (FIPS 203) for key establishment and ML-DSA (FIPS 204) for signatures; applies_to says which use each entry covers. If you need a single answer, read the first element.

Evidence

Certificates extracted from binary files are byte-offset findings, not line-based ones. Their entries carry line: 0 by design, and the location is given in the match string:

pe_attribute_certificate_table@0x<offset>: a certificate from the Windows PE attribute certificate table.
pe_embedded_pem@0x<offset>: a PEM block embedded in the file.

Verdict

verdict is evaluated in this order, No Cryptography Found, Risk Cryptography Found (risk_summary.overall.unsafe is greater than 0), Cryptography Found.

Note: No Cryptography Found is returned both when an analyzed file yields no cryptographic assets and when the file type is not covered by CBOM analysis. The verdict does not distinguish between these two cases.

Last updated on

Was this page helpful?