Before You Pick An Algorithm, Find The Cryptography: The Case For A CBOM Built In CI

A piece published on devops.com argues that post-quantum cryptography migration starts with discovering where vulnerable cryptography exists, not with swapping algorithms ^[1]. That reframes the first deliverable from a migration plan into an inventory, and it locates the work where delivery teams already have leverage points: the build pipeline, which can continuously collect cryptographic metadata and tie it to builds, images and deployed workloads ^[4].

The public conversation runs the other way. It moves quickly to RSA, elliptic curve cryptography, ML-KEM, digital signatures and hybrid key exchange ^[14]. According to the devops.com piece, the harder task for DevOps teams is determining where vulnerable cryptography exists, which applications and infrastructure depend on it, who owns those dependencies, and how hard each one will be to change ^[2]. NIST's Migration to Post Quantum Cryptography project identifies cryptographic visibility and risk management as a core workstream and recommends building and maintaining a comprehensive cryptographic inventory to guide migration ^[5]. The scope named there is broader than a certificate list: algorithms, protocols, keys, certificates, applications, services, devices and data flows ^[6], which is eight categories where many organisations currently track one ^[7].

The reason a certificate inventory is not enough is that cryptography enters the lifecycle at several points nobody owns jointly. A developer can pull in a cryptographic dependency through a package, a CI pipeline can sign an artifact, a container can inherit a TLS library from its base image, Kubernetes can terminate TLS at an ingress controller, and a cloud service can manage keys through a KMS or HSM, and none of these necessarily shows up in a conventional certificate inventory ^[8]. Before production, Git repositories use HTTPS or SSH, dependency managers fetch packages over authenticated connections, CI systems talk to external services over TLS, artifact repositories depend on certificates and authentication, and signing systems may use public key cryptography for provenance ^[9]. At runtime, cluster control planes use certificates, service meshes encrypt service-to-service traffic, APIs validate signed tokens, databases encrypt stored data, and cloud platforms manage keys ^[10]. One application can therefore depend on cryptography supplied by several infrastructure layers owned by different teams ^[11].

This is why grep is not a strategy. A source search for RSA, AES, ECDSA or SHA256 will not reveal the complete picture, because applications inherit cryptographic behaviour from frameworks, operating systems, libraries, containers, infrastructure components and managed services ^[12]; the footprint is better modelled as a dependency graph than a list of algorithms ^[13]. SBOMs help map software components, but the piece positions CBOMs and cryptographic inventories as the layer that gives deeper visibility into keys, certificates, protocols and algorithms ^[3]. The stated payoff for keeping that inventory alive rather than annual is crypto agility, migration prioritisation, and reduced exposure to harvest-now-decrypt-later risk ^[15].

Two things separate a real programme from a slide. First, whether the CBOM is generated per build and diffed, since a living inventory is the requirement ^[15] and an inventory that ages is a report. Second, whether ownership is recorded alongside each finding, because the ownership question is part of the discovery problem as described ^[2] and inherited cryptography from base images and ingress layers crosses team boundaries ^[11]. Watch also whether infrastructure and SaaS dependencies get in scope at all, given that the hiding places named include containers, CI/CD, Kubernetes, cloud services and SaaS platforms ^[16].