This article is part of Qinsight’s cryptographic posture management use case series, connecting five security outcomes with practical operational workflows.
In brief
- A service-level CBOM answers which cryptography a business function depends on, but only with a defined boundary, identifiable objects and relationships backed by evidence.
- Choose the decision the CBOM must support first, collect complementary evidence from network, build, host, cloud key-service and service-catalog sources, and keep each source's time, method and gaps visible.
- Model relationships precisely and record coverage alongside findings, so a larger object count is never mistaken for completeness.
A security leader asks for the cryptographic estate of a critical business service. The available evidence arrives as a certificate report, a software dependency list, a cloud-key export and several architecture diagrams. Each contains useful information. None, on its own, explains how the service depends on cryptography.
A cryptographic bill of materials, or CBOM, can provide a structured record of that estate. To support operational decisions, it needs a defined boundary, identifiable cryptographic objects and relationships backed by evidence.
The starting point is the business service and the questions its owners need to answer. Which certificate could interrupt it? Which workloads contain an affected library? Which applications depend on a key scheduled for retirement? A useful CBOM makes those questions easier to investigate.
Define the service and the decision
Consider an illustrative supplier-payment service. It includes a portal, an API, processing workloads, a database and a connection to a banking partner. Identity services, a certificate authority and a cloud key-management service provide shared dependencies.
The service boundary should name the environments, regions, application versions and external relationships in scope. Decide whether the first assessment includes production only, recovery environments, build pipelines or all of them. Record the exclusions.
Then choose the decision the CBOM should support. Certificate continuity requires evidence about deployment and validation paths. A library assessment requires software identity and deployment records. A key-retirement review requires data and consumer dependencies.
The service may eventually need all of these views. Starting with a concrete decision helps the team identify the evidence required and avoid presenting a large but incomplete collection as a finished estate.
Choose the right level of cryptographic estate
An application, a running workload and a network endpoint are related, but they describe different scopes. A CBOM can be produced for a defined scope at any of these levels when the supporting evidence is available.
| Scope | Evidence to assemble | Useful question |
|---|---|---|
| Asset or device | Relevant stores, key metadata, software and configuration on a named host or appliance. | What cryptography is associated with this device? |
| Network endpoint | Hostname, port, presented certificates and observed protocol behavior. | What protection was observed on this connection? |
| Application | Build identity, libraries, cryptographic functions and configured external dependencies. | What does this application contain or depend on? |
| Workload | Deployed image or build, environment, mounted material and observed service relationships. | What is associated with this deployed instance? |
| Business service | Linked applications, workloads, endpoints and shared or supplier dependencies. | Which cryptographic changes or failures could affect this service? |
The word “endpoint” also needs a definition. An endpoint-management record may describe a laptop or server, while a network assessment describes a listener. Name the scope explicitly so readers do not infer device-wide coverage from a single TLS observation.
A service-level CBOM connects these views without erasing their differences. Shared dependencies should retain stable identities so the same key service or library does not become an unrelated object in every application record.
Collect evidence from complementary sources
Network observations can reveal certificates, protocol versions and negotiated behavior. They usually cannot establish all the libraries, internal connections or data-encryption keys used by an application.
Build and software evidence can identify included components and cryptographic implementations. Host and configuration evidence can show stores, settings and deployment relationships. Authorized cloud and key-service integrations can provide key identifiers, attributes and relevant permissions. Service catalogs and owners supply business context.
Each source should retain its collection time, method and boundary. A supplier statement about supported algorithms, a setting that enables an algorithm and a connection that used it are different observations. The CBOM and associated records should make those differences visible.
Qinsight’s approach to cryptographic discovery treats the collection scope and its gaps as part of the evidence. For the payment service, an unassessed banking connection or an inaccessible recovery workload should remain an explicit gap, with an owner for follow-up.
Model objects and relationships precisely
Identify certificates by stable attributes such as their fingerprint and issuer context. Record key identifiers without collecting private material. Identify software with the version and build information needed to distinguish deployments. Keep an algorithm’s identity separate from the library that implements it.
Then describe the relationship supported by the evidence. An endpoint presents a certificate. A workload uses a configuration. An application depends on a software component. A service relies on a shared signing system. These relationships support different questions and should not be collapsed into an ambiguous “connected to” label.
The OWASP CycloneDX CBOM guide describes cryptographic representations for algorithms, certificates, protocols and related cryptographic material. Its dependency model also distinguishes dependencies from capabilities provided by a component. An implementation capability does not establish runtime use.
Business ownership, incident conclusions and some operational relationship types may require documented properties or linked records outside the portable CBOM. State how those extensions are represented and what a receiving system can interpret. A format-compatible file should not imply that every consumer understands the full operational model.
Produce a snapshot that another team can interpret
Give the CBOM a unique identity, version, creation time and clear subject. State the discovery period and the environments represented. Connect it to the source records or references needed to inspect important claims.
Keep the export bounded. A certificate discovered on a public gateway supports a claim about that observation. It does not establish encryption between the gateway and its origin, or the protection of data at rest. Those require additional evidence.
Record coverage alongside findings. Include known exclusions, failed collection attempts and relationships awaiting confirmation. A new version should explain whether a difference reflects an actual service change, improved discovery or a correction to the inventory.
The CBOM should carry metadata appropriate to the receiving audience. Private keys and secret values do not belong in it. Architecture details and identifiers can also be sensitive, so use access and sharing controls suited to the service.
Our comparison of CBOMs and maintained cryptographic inventories explores their relationship. A CBOM can represent a build or an operational snapshot; the maintained inventory provides the continuing context needed to revisit it.
Use the service view to make a concrete decision
Return to the supplier-payment example. An expiring certificate is useful to the security team when its record identifies the partner connection, the initiating workload and the owner who can coordinate a replacement.
A library finding becomes actionable when the relevant build can be connected to production and recovery workloads. A key-retirement proposal becomes reviewable when the known data stores and decrypting applications are identified, with unresolved historical dependencies still visible.
The CBOM does not by itself prove that a failure will occur or that a component is exploitable. It supplies an organized evidence base for assessment. Service criticality, incident facts, validation behavior and change constraints complete the decision.
For leaders, useful measures include the proportion of important service components with current evidence, the number of cryptographic objects with accountable owners and the unresolved dependencies blocking a decision. These measures explain the value of the work more clearly than an inventory count alone.
How Atlas supports a service-level cryptographic estate
Atlas brings discovery evidence into a cryptographic inventory and connects it to available system and business context. That gives teams a foundation for examining the estate at the level of an asset, application, endpoint, workload or business service.
The practical workflow is to agree a service boundary, collect the available evidence, review object identities and relationships, and produce a scoped view with the remaining gaps identified. Refresh that view when relevant deployments, certificates, keys or dependencies change.
A first pilot should produce something the service owner can use: a defined estate, traceable observations and a short list of decisions or missing evidence. The CBOM is then a repeatable record of the service’s cryptography, supported by an inventory that can be maintained as the service evolves.
Explore the use case series
- Cryptographic posture management use cases
- Prevent certificate outages with service context
- Appliance exploits and cryptographic impact
- Exposed private keys and service impact
- Cryptographic library CVEs and service impact
- Safer key and certificate rotation
Related reading
- Cryptographic posture management use cases: Explore five security outcomes, 36 operational use cases and PQC migration.
- Safer key and certificate rotation: Use a scoped cryptographic estate to plan changes and verify dependent systems.
- CBOM and cryptographic inventory: the two essential layers of cryptographic visibility: Understand portable records and maintained operational context.
Sources
- OWASP CycloneDX: Authoritative Guide to CBOM: Cryptographic asset types, dependencies and implementation guidance.
- OWASP CycloneDX: Cryptography Bill of Materials: Overview of cryptographic representation within the BOM model.
Next step: Choose one critical business service and define the cryptographic decision its first CBOM should support. Scope the service with Qinsight.
Build the evidence behind the argument.
Start with one accredited boundary or one delivered system and produce evidence a reviewer will accept.
