Crypto Bom

Cryptographic BOM

Use this skill when the user wants to know what cryptography a codebase or host actually uses — for post-quantum migration planning, crypto policy compliance, or finding weak primitives.

Read reference/safety.md first. CBOM source analysis uses the atom companion, which needs no JDK on the native-binary platforms (linux-amd64, linux-arm64 glibc, linux-amd64-musl, darwin-arm64, windows-amd64). Only the jar-based triples (darwin-amd64, windows-arm64, linux-arm64-musl) require Java >= 23 and fail silently below it, so verify java -version there before interpreting a thin CBOM.

Generate

cbom -o /absolute/path/to/cbom.json /absolute/path/to/project

The cbom command is not merely an alias with a flag. Invoking it sets:

Two combinations are rejected, not silently ignored:

• cbom --component-type <t> — use cdxgen --include-crypto instead when you need component-type filtering.
• cbom -t os — crypto evidence collection analyses source with atom, which is meaningless and extremely slow against an OS inventory. Use obom for operating-system installations (see os-hardware-inventory).

The equivalent explicit invocation, when you want to vary one part:

cdxgen --include-crypto --evidence --deep \
  -o /absolute/path/to/cbom.json /absolute/path/to/project

What gets inventoried

• cryptographic-asset components for algorithms, certificates, keys, and protocols
• certificates and trusted key material discovered in the tree or host
• source-derived algorithm inventory from JavaScript and TypeScript via lightweight AST analysis

Note two modelling facts that surprise people:

1. Cryptographic assets do not carry purls. That is correct; they are not packages. Do not treat a missing purl as a gap, and never invent one.
2. Source-derived algorithm components are constrained to stay validator-safe: cdxgen emits only algorithms it can map to a known OID. An algorithm you can see in the source but not in the CBOM was most likely unmappable, not missed.

Auditing the CBOM

cbom -o /absolute/path/to/cbom.json /absolute/path/to/project \
  --bom-audit --bom-audit-categories cbom

The cbom category alias enables both rule sets:

crypto-bom works as an alias for the same pair.

Audit an existing CBOM after the fact:

cdx-audit --bom /absolute/path/to/cbom.json --direct-bom-audit --categories cbom

Exploring the result

In cdxi (see bom-explore):

• .cryptos — the full cryptographic asset list
• .sourcecryptos — only the JavaScript/TypeScript source-derived algorithm components
• .trusted — trusted keys and certificates

Reach for .sourcecryptos when the user's question is about code-level algorithm usage rather than the certificates and keys shipped alongside it.

Crypto usage in Go, with data flow

For Go projects, evinse can trace crypto data flow rather than just presence — which values reach a cryptographic operation:

cdxgen -t go -o /absolute/path/to/bom.json /absolute/path/to/project
evinse -i /absolute/path/to/bom.json -o /absolute/path/to/bom.crypto.json \
  -l go --with-data-flow \
  --golem-dataflow crypto --golem-dataflow-pattern-packs crypto \
  /absolute/path/to/project

Prioritize components carrying cdx:golem:cryptoDataFlow=true and cdx:golem:cryptoDataFlowCount, then pivot on the rendered cryptographic-asset algorithms. See bom-evidence for the full Golem surface.

Never surface raw plaintext, ciphertext, key material, or embedded file contents from Golem output. Review through the emitted cdx:golem:* counts, categories, taint kinds, and algorithm/OID pivots.

Runtime crypto observation

To see crypto actually exercised at runtime rather than inferred from source, tracebom has dedicated probes:

tracebom --cmd "node app.js" --trace-crypto --crypto-probe-mode <mode> \
  -o /absolute/path/to/trace-cbom.json

See runtime-trace-bom.

Reference

• CBOM audit rules: https://cdxgen.github.io/cdxgen/#/BOM_AUDIT
• Custom properties: https://cdxgen.github.io/cdxgen/#/CUSTOM_PROPERTIES
• Go Evinse and Golem: https://cdxgen.github.io/cdxgen/#/GO_EVINSE_GOLEM