OWASP CycloneDX v1.6 CBOM Schema & Automated Discovery Guide
Manual spreadsheets go stale on the next deployment. Build a machine-verifiable Cryptographic Asset Inventory (CBOM) using OWASP CycloneDX v1.6 cryptoProperties records so internal engineering and external auditors share one canonical ledger of algorithms, certificates, protocols, and keying data descriptors.
CycloneDX v1.6 cryptoProperties Reference Structure
In CycloneDX v1.6, every cryptographic finding is modeled inside components[] with "type": "cryptographic-asset". Rather than burying cipher details in free-text notes, the specification defines structured objects for algorithm primitives, X.509 certificate records, transport protocol negotiations, and keying data descriptors (such as key state, bit size, and rotation dates without ever exporting secret values), joined together through the top-level dependencies[] graph.
settlement-gateway.cbom.cdx.jsonCycloneDX v1.6 JSON{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:7e91f01c-6831-4a9b-9d10-8102c9418021",
"version": 1,
"metadata": {
"timestamp": "2026-11-01T09:00:00Z",
"component": {
"type": "application",
"name": "settlement-gateway-api",
"version": "4.12.0"
}
},
"components": [
{
"type": "cryptographic-asset",
"bom-ref": "crypto/alg/ml-kem-768",
"name": "ML-KEM-768",
"cryptoProperties": {
"assetType": "algorithm",
"oid": "2.16.840.1.101.3.4.4.2",
"algorithmProperties": {
"primitive": "kem",
"parameterSetIdentifier": "768",
"executionEnvironment": "software-plain-ram",
"implementationPlatform": "x86_64",
"nistQuantumSecurityLevel": 3
}
}
},
{
"type": "cryptographic-asset",
"bom-ref": "crypto/alg/rsa-2048-legacy",
"name": "RSA-2048",
"cryptoProperties": {
"assetType": "algorithm",
"oid": "1.2.840.113549.1.1.1",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "2048",
"nistQuantumSecurityLevel": 0
}
}
},
{
"type": "cryptographic-asset",
"bom-ref": "crypto/cert/ingress-leaf-2026",
"name": "CN=api.settlement.internal",
"cryptoProperties": {
"assetType": "certificate",
"certificateProperties": {
"subjectName": "CN=api.settlement.internal, O=Example Corp",
"issuerName": "CN=Example Issuing CA G3",
"notValidBefore": "2026-06-01T00:00:00Z",
"notValidAfter": "2027-06-01T00:00:00Z",
"certificateFormat": "X.509",
"signatureAlgorithmRef": "crypto/alg/rsa-2048-legacy"
}
}
},
{
"type": "cryptographic-asset",
"bom-ref": "crypto/proto/tls-1-3-edge",
"name": "TLSv1.3",
"cryptoProperties": {
"assetType": "protocol",
"protocolProperties": {
"type": "tls",
"version": "1.3",
"cipherSuites": [
{
"name": "TLS_AES_256_GCM_SHA384",
"algorithms": [
"crypto/alg/ml-kem-768"
]
}
]
}
}
}
],
"dependencies": [
{
"ref": "crypto/proto/tls-1-3-edge",
"dependsOn": [
"crypto/cert/ingress-leaf-2026",
"crypto/alg/ml-kem-768"
]
}
]
}Five CBOM Fields External Auditors Inspect First
| JSON Path | Schema Function | Audit Verification Rule |
|---|---|---|
| cryptoProperties.assetType | Classifies each cryptographic component as algorithm, certificate, protocol, or keying-data descriptor. | Reject flat spreadsheets lacking structured assetType separation; auditors need explicit links between X.509 certificates and underlying signature primitives. |
| cryptoProperties.oid | Unambiguous ASN.1 Object Identifier (for example 2.16.840.1.101.3.4.4.2 for ML-KEM-768). | String names vary across OpenSSL, BoringSSL, and Java JCA; ASN.1 OIDs allow deterministic automated policy checks against NIST FIPS 203-205. |
| algorithmProperties.primitive | Distinguishes key encapsulation (kem), digital signature (signature), authenticated encryption (ae), and hash primitives. | Isolate asymmetric primitives (nistQuantumSecurityLevel = 0) from symmetric AES-256-GCM or SHA-384 primitives that remain quantum-resilient. |
| algorithmProperties.executionEnvironment | Documents whether operations execute in software-plain-ram, hardware-tee, or FIPS 140-3 HSM modules. | Essential for NSA CNSA 2.0 and EU DORA scoping, since HSM-backed keys require vendor firmware validation rather than a simple library patch. |
| certificateProperties.notValidAfter | UTC expiration timestamp of roots, issuing CAs, and device identity certificates. | Flag any RSA or ECDSA certificate expiring on or after 2030-01-01 against the NIST IR 8547 deprecation threshold. |
Three-Stage Discovery Workflow: Syft, CBOMkit & Live Handshake Verification
Static code scanning alone cannot prove what a production load balancer actually negotiates on the wire, and network scanning alone cannot locate dormant RSA calls inside batch jobs. Combine repository AST extraction with container package SBOMs and live port-443 TLS verification.
ci-cbom-pipeline.shPOSIX Shell# 1. Generate container & library SBOM baseline with Anchore Syft (CycloneDX v1.6 JSON)
syft scan registry.internal/settlement-gateway:4.12.0 -o cyclonedx-json=sbom.cdx.json
# 2. Run static AST cryptographic discovery via Sonar Cryptography / IBM CBOMkit CLI
# Scans Java JCA, Python cryptography, Go crypto/*, and C/OpenSSL provider invocations
sonar-scanner \
-Dsonar.projectKey=settlement-gateway \
-Dsonar.cbom.output=cbom-ast.cdx.json
# 3. Validate CycloneDX v1.6 JSON schema compliance before archiving for external auditors
cyclonedx validate --input-file cbom-ast.cdx.json --input-version v1_6 --fail-on-errorsStage 1: Static AST Cryptographic Extraction (Sonar Cryptography & CBOMkit)
Abstract Syntax Tree rules inspect Java Cryptography Architecture (Cipher.getInstance, KeyPairGenerator), Python cryptography, Go crypto/tls, and OpenSSL C calls to record exact parameter sets and line numbers inside your CycloneDX v1.6 export.
Stage 2: Container & Shared Library Correlation (Anchore Syft)
Pair AST findings with container filesystem manifests from syft to verify whether base images ship OpenSSL 3.5+ (native ML-KEM, ML-DSA, and SLH-DSA providers) or older OpenSSL 1.1.1 / 3.0 builds incapable of hybrid key exchange without upgrades.
Stage 3: Active Wire-Level TLS 1.3 Reconciliation
Reconcile your static CBOM against live ingress behavior by testing public endpoints on Q-Day Check (https://qdaycheck.com/). Confirming negotiated X25519MLKEM768 (0x11EC) handshakes proves that CDN edge policies and TLS termination proxies match your documented CycloneDX protocol assertions.
Reviewed by Evelyn Mercer, Principal Cryptographic Governance & GRC Editor
Reviews OWASP CycloneDX CBOM schemas, federal post-quantum procurement mandates, and PKI governance frameworks.
Last reviewed:
All regulatory mandate timelines, CycloneDX v1.6 schema references, audit scoping weights, and RFP clauses are reviewed every 3 months, or sooner whenever NIST, NSA, OMB, ENISA, or the Australian Signals Directorate issues updated guidance.
AI-assistance & editorial check: Research outlining and formatting are assisted by AI tools in an offline draft workflow. Nothing on this site publishes automatically without verification. A named human editor opens and verifies every primary source link, command snippet, and factual statement prior to publication. See our Editorial Policy and Corrections Policy.
Verified Primary Sources
- OWASP CycloneDX v1.6 Specification: Cryptographic Asset Inventory (CBOM) (OWASP Foundation, Spec v1.6)
- IBM CBOMkit & Sonar Cryptography Open-Source Scanner Documentation (PQCA / Linux Foundation Post-Quantum Cryptography Alliance, AST Discovery)
- NIST Computer Security Objects Register (CSOR): FIPS 203, 204 & 205 ASN.1 OIDs (National Institute of Standards and Technology, Official OIDs)
- Anchore Syft CLI: CycloneDX JSON Output Format (Anchore Open Source, Container Inventory)
Get CycloneDX CBOM Schema & Tooling Updates
Enterprise CBOM & PQC Audit GovernanceSave your email for quarterly notes when OWASP CycloneDX, NIST CSOR OID registries, or open-source CBOM scanners ship new releases.