CycloneDX CBOM example and field guide

From inventory to a dated artifact

What does a CBOM contain?

To create one for your own environment, follow How to generate a CBOM with Vista Core. To inspect an existing file, open the CycloneDX JSON viewer.

Vista generates a CBOM from the inventory in a selected Scope. The result is a frozen snapshot: later discovery changes the inventory, not the bytes of an existing artifact. Current exports use CycloneDX 1.7. Older artifacts retain their original declared version.

Start by checking what was in scope and when the snapshot was generated. Then follow the components and their references. A valid file can still reflect incomplete collection; preserve coverage gaps alongside your interpretation.

Worked example: hybrid exchange, classical authentication

Search the file for X25519MLKEM768. Read its cryptoProperties and the algorithm role encoded in its bom-ref. Compare the protocol and certificate-related records sharing its context: the example also contains RSA certificate-key and SHA256-RSA certificate-signature entries.

{
  "type": "cryptographic-asset",
  "bom-ref": "crypto/algorithm/e3ac2c9f-685d-5270-82a0-eedc7503c99c/key_exchange/x25519mlkem768",
  "name": "X25519MLKEM768",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "kem",
      "cryptoFunctions": [
        "keygen",
        "encapsulate",
        "decapsulate"
      ],
      "classicalSecurityLevel": 192,
      "nistQuantumSecurityLevel": 3,
      "certificationLevel": [
        "none"
      ]
    }
  }
}

1. Identify the function. A key-exchange algorithm and a certificate signature solve different problems. Hybrid exchange does not make classical authentication post-quantum.
2. Follow the context. Use vista:asset-id to find related asset records and dependencies[].ref / dependsOn for explicit dependency edges. Shared asset identity alone does not establish a dependency.
3. Read properties precisely. A catalogue security level describes the algorithm; it is not a whole-system score. certificationLevel: ["none"] does not establish a CAVP or CMVP validation.
4. Keep uncertainty visible. An absent component is not proof that it does not exist. This example has no library components; other inventories and exports may contain them.

The export illustrates why a successful hybrid handshake and an outstanding migration finding can coexist. To decide what to change, review the corresponding configuration and findings in Vista, plus your collection coverage and intended clients.

A guided tour of a Vista CBOM

Generate and verify your own baseline

1. Collect authorized discovery evidence and review the inventory, identity questions and collection gaps.
2. Choose a Scope that matches the service or environment you intend to assess.
3. Open Risk & Compliance → Bills of Materials → Generate. Leave Kind on Cryptographic (CBOM), select the Scope and give the snapshot a useful name.
4. Download the canonical CycloneDX JSON. Record its Scope, scope version, generation time and SHA-256 from the artifact record.
5. Compute SHA-256 over the downloaded file and compare it with the recorded hash. Keep the original bytes: reformatting or editing the JSON changes its hash.
6. After a migration step, collect new evidence and generate a new snapshot of the same intended boundary. Review scope changes before interpreting differences.

On Linux use sha256sum your-cbom.json; on macOS use shasum -a 256 your-cbom.json; in PowerShell use Get-FileHash .\your-cbom.json -Algorithm SHA256. A matching hash checks integrity against the saved value; it does not establish completeness or compliance.

Follow the full Vista CBOM walkthrough →

Algorithm anatomy: small teaching files

The three downloads below are deliberately minimal CycloneDX 1.6 teaching snippets, not Vista exports. They remain useful for isolating an algorithm record, but they do not represent the current product’s complete 1.7 output, a live observation or a compliance report. Use the workflow above to obtain an operational Vista artifact.

The hybrid ingredient example contains only ML-KEM: it does not encode a complete hybrid construction. The anonymized 1.7 download above shows the complete structure of the supplied Vista export.

Classical signature algorithm

An algorithm inventory can identify a classical signing dependency. It does not by itself identify every key, signer, or verifying client.

{
  "type": "cryptographic-asset",
  "name": "RSA-2048",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "signature",
      "parameterSetIdentifier": "2048"
    }
  }
}

Hybrid key-agreement ingredients

This example inventories a KEM algorithm. A real hybrid protocol record must also describe the classical component, protocol binding and dependencies; this file does not prove a negotiated hybrid connection.

{
  "type": "cryptographic-asset",
  "name": "ML-KEM-768",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "kem",
      "parameterSetIdentifier": "768"
    }
  }
}

Symmetric encryption algorithm

A symmetric algorithm entry says nothing by itself about how its keys were transported or wrapped. Inspect those dependencies separately.

{
  "type": "cryptographic-asset",
  "name": "AES-256-GCM",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "ae",
      "parameterSetIdentifier": "256"
    }
  }
}

Reading checklist

1. Check bomFormat, specVersion and artifact version.
2. Identify the system or scope the artifact describes.
3. Read the asset type and algorithm properties.
4. Follow references and dependencies where present.
5. Find when and how evidence was collected.
6. Record missing context before making a migration decision.

A syntactically valid file can still be incomplete. None of these examples includes private key material. For operational generation, use the Vista CBOM guide.

Sources and further reading

• CycloneDX CBOM resources
• CycloneDX 1.7 JSON reference
• CycloneDX 1.6 JSON reference