I'm doing some market research before investing more time in a possible solution and would like to understand how organizations handle this in practice. If your team needed to determine which workloads use RSA versus ECDSA certificates, which images include OpenSSL 1.x, BouncyCastle, or other cryptographic libraries, which applications terminate TLS directly versus relying on an ingress or load balancer, and which workloads may eventually require post-quantum cryptography migration, where would you get that information? Are you using security platforms, custom scripts, SBOMs, network telemetry, CBOMs, or internal documentation—or is this generally not tracked? I'm trying to figure out whether this is a genuine operational problem in some environments or something most teams consider unnecessary to build for.
4 Answers
This is often described as a Cryptography Bill of Materials, or CBOM. Some application and supply-chain inventory tools are beginning to answer parts of the question, such as identifying cryptographic libraries and certificates, while deeper runtime and migration analysis is still developing. In many organizations, the remaining information is kept in architecture documents or maintained by the service owner, architect, or platform team rather than automatically inventoried.
Network observability can provide another practical source of data. TLS inspection and traffic topology features can show where encrypted connections are being established and, in some environments, identify flows that meet post-quantum cryptography requirements. This is especially helpful for workloads whose TLS termination point isn’t obvious from deployment configuration.
This is usually handled as a layered policy problem rather than through one inventory system. Platform teams can enforce controls such as mTLS and standardized certificate issuance, while development and CI pipelines check dependencies, secrets, vulnerabilities, and image provenance. Signing images with tools such as Sigstore or Cosign can verify that they came through the approved build process. That still leaves a gap around understanding actual runtime cryptographic usage and identifying future PQC migration work.
SBOMs were useful for identifying libraries that were packaged into images, but they didn’t reliably show what was actually happening at runtime. We ended up using an eBPF-based sensor to observe real cryptographic and network activity instead. That helped distinguish installed components from libraries and protocols that workloads were actively using.
The distinction between present in the image and actually used seems important. Runtime visibility sounds much more useful for mapping real TLS and algorithm exposure than an SBOM alone.
That matches what I’m hearing: policy, CI, and provenance are connected, but none of them necessarily show which algorithms or certificates will need PQC attention.