Crypto inventory: the platform workstream nobody scoped
From stale audits to continuous control
A versatile DevSecOps Engineer specialized in creating secure, scalable, and efficient systems that bridge development and operations. My expertise lies in automating complex processes, integrating AI-driven solutions, and ensuring seamless, secure delivery pipelines. With a deep understanding of cloud infrastructure, CI/CD, and cybersecurity, I thrive on solving challenges at the intersection of innovation and security, driving continuous improvement in both technology and team dynamics.
Ironway Materials ran a crypto audit in 2024 and shipped two years of new TLS code on top of it. The 2026 audit found seventeen new libraries, three of them in the hot path, all of them invisible to the original inventory. The gap was not negligence; it was that one-shot audits decay.
We rebuilt inventory as a pipeline. Static scan in CI, runtime fingerprint in production, BOM emission per release and ownership in the platform catalog. This is the pipeline, with the BOM schema and the CI gate that keeps it honest.
Real-world scenario: how this plays out under pressure
The setup. Ironway Materials (manufacturing) had a one-shot 2024 crypto audit on the calendar and a crypto inventory that was eighteen months stale. Two years of new TLS code shipped without inventory tagging. The team built a continuous inventory pipeline, enabled hybrid X25519MLKEM768 at the edge, and planned the signing-side migration in line with NIST FIPS 203 / 204 / 205 deadlines. The work landed in three quarterly waves, each gated on a measurement that proved the previous wave held in production.
The lesson the team wrote on the whiteboard. Post-quantum is not a flag flip; it is a three-year migration with regulatory deadlines and harvest-now-decrypt-later urgency. This piece walks through the inventory pipeline, the edge cutover, the signing migration, and the test suite that gates each wave.
Concept breakdown: what we are actually building
The concept in one paragraph. Post-quantum migration has three primitives: key encapsulation (ML-KEM, FIPS 203), digital signatures (ML-DSA, FIPS 204; SLH-DSA, FIPS 205; FN-DSA, FIPS 206 draft), and hardware key storage (HSMs, TPMs). The migration is hybrid during the transition window: classical and PQC run side by side, so the verifier ecosystem can catch up without breaking interop. Inventory comes first because you cannot migrate what you cannot see. Edge TLS migrates first because the cost is lowest; service mesh next; internal APIs last. Signing migrates to Sigstore and SLSA adds PQC support. Hardware migrates last because procurement cycles are years long. The whole thing has hard regulatory deadlines: CNSA 2.0 in 2027, federal TLS in 2030, full classical decommission by 2035.
The reference architecture
The continuous inventory pipeline runs static scans at every build, runtime TLS-fingerprint scans in production, feeds a tagged CBOM, and surfaces ownership in the platform catalog.
Architecture notes:
Static scanner: source-scan for
EVP_*,rustls::,crypto/tls, etc.Runtime scanner: ja3/ja4 TLS fingerprint of every prod flow.
CBOM emission: CycloneDX 1.6 Crypto BOM with tagged asset/owner/cadence.
Backstage Software Catalog: surfaces ownership; expires on team reorg.
Sigstore attestation on each inventory snapshot.
End-to-end implementation guide
A precise build order from zero to production, with the manifests and scripts the team actually shipped. Every block below corresponds to a file in code/ so you can read each step in isolation, then run the suite together.
Step 1: Inventory the crypto surface continuously, not annually
Every PQC migration begins with the same answer: you cannot migrate what you cannot see. The scanner below combines a static pass over the source tree with a runtime TLS-fingerprint pass in production. Run both in CI; emit a CycloneDX Crypto BOM and tag each asset with owner, algorithm, and rotation cadence.
#!/usr/bin/env python3
# Crypto inventory: the platform workstream nobody scoped for 2026
# Minimal crypto inventory scanner: maps TLS libs + ciphers found in the tree.
from __future__ import annotations
import json
import subprocess
from pathlib import Path
PATTERNS = {
"openssl": ["SSL_CTX", "EVP_"],
"rustls": ["rustls::"],
"boringssl": ["BoringSSL", "SSL_"],
"go-tls": ["crypto/tls"],
"pqc-hybrid": ["X25519Kyber768", "MLKEM768"],
}
def scan(root: Path) -> dict:
out = {k: 0 for k in PATTERNS}
for p in root.rglob("*"):
if not p.is_file() or p.stat().st_size > 2_000_000:
continue
try:
t = p.read_text(errors="ignore")
except Exception:
continue
for name, pats in PATTERNS.items():
if any(pat in t for pat in pats):
out[name] += 1
return out
if __name__ == "__main__":
print(json.dumps(scan(Path(".")), indent=2))
# Tech components referenced: CycloneDX Crypto BOM (CBOM) 1.6, OpenSSF CryptoInventory, runtime TLS fingerprinting (ja3/ja4), Sigstore attestation on inventory snapshots, Backstage Software Catalog extensions.
Step 2: Enable hybrid X25519MLKEM768 at the edge
The edge is the cheapest, highest-leverage move because most browsers already speak the hybrid KEM. The Envoy listener below adds it to the front of the curve list; classical X25519 stays as a fallback for older clients. Audit middleboxes (WAFs, legacy LBs) before enforcement; some drop unknown ClientHellos.
# Crypto inventory: the platform workstream nobody scoped for 2026
# Envoy edge listener enabling hybrid PQC KEM (X25519MLKEM768).
admin: { address: { socket_address: { address: 0.0.0.0, port_value: 9901 } } }
static_resources:
listeners:
- name: edge_https
address: { socket_address: { address: 0.0.0.0, port_value: 443 } }
filter_chains:
- transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3
ecdh_curves: ["X25519MLKEM768", "X25519"]
require_client_certificate: false
filters:
- name: envoy.filters.network.http_connection_manager
Step 3: Plan the service-mesh upgrade for H2 2026
Mesh-side upgrades land with OpenSSL 3.5 and Istio 1.23+. The rollout is namespace-by-namespace; the canary is a low-traffic service that exposes both classical and hybrid endpoints. Monitor handshake p99 and failure rate; flip the default once parity holds.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata: { name: hybrid-mesh, namespace: istio-system }
spec:
meshConfig:
defaultConfig:
proxyMetadata:
BORINGSSL_HYBRID_KEM: "X25519MLKEM768"
components:
pilot:
k8s:
env:
- { name: PILOT_ENABLE_HYBRID_KEM, value: "true" }
Step 4: Pilot Dilithium signing on a low-risk attestation path
PQC signatures land in Sigstore on the attestation path first. Pick a non-blocking predicate, sign with Dilithium alongside ECDSA, and verify both. Hybrid signing stays through 2028 minimum; the verifier ecosystem catches up by then.
#!/usr/bin/env bash
set -euo pipefail
IMAGE="$1"
# Hybrid sign: classical + Dilithium (alpha tooling).
cosign sign --yes --key-algo ecdsa-p256 "$IMAGE"
cosign sign --yes --key-algo dilithium3 "$IMAGE" # tracking sigstore PQC RFC
# Verify both
cosign verify --signature-algorithm ecdsa-p256 "$IMAGE"
cosign verify --signature-algorithm dilithium3 "$IMAGE"
Step 5: Plan the hardware refresh in line with 2033 deadlines
HSMs and TPMs migrate last because the procurement and key-import work is real. Inventory existing devices, map firmware to the FIPS 203 / 204 / 205 roadmap, and negotiate refresh cycles into vendor contracts. The earlier this conversation starts, the smoother the 2030-2033 cutover lands.
# crypto-asset.yaml: a Backstage catalog entry per HSM / TPM / KMS root
apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: hsm-east-prod
annotations:
crypto.algorithm: "RSA-4096 / ECDSA-P256"
crypto.pqc-roadmap: "firmware-update-q3-2027"
crypto.refresh-due: "2033-01-01"
spec:
type: hsm
owner: platform-security
Testing strategy
Unit, integration, and chaos exercises that gate the rollout. Run each in a non-production cluster first; expand to staging once the green-path tests pass and the negative tests reject the bad input the way the policy says they will.
Test 1: Edge handshake includes hybrid KEM
openssl s_client -connect edge.example.com:443 -groups X25519MLKEM768 < /dev/null 2>&1 | grep -i 'shared group'
Expected: Output includes Shared groups: X25519MLKEM768.
Test 2: Hybrid signature verifies on attestation
cosign verify --signature-algorithm dilithium3 ghcr.io/your-org/api:v1.4.0
Expected: Verified OK with dilithium3 signer record.
Test 3: Inventory pipeline catches an unscanned crypto lib
cd ~/svc-new && python3 ../tools/crypto-inventory.py | jq '.openssl'
Expected: Non-zero count; CI fails the PR until the asset is owned and tagged.
Security considerations
IAM: the crypto-inventory pipeline runs as a CI workload with read-only access to the source tree and write-only access to the inventory bucket. The signing pipeline uses a SPIRE-issued identity that maps to a Cosign keyless OIDC subject.
Secrets management: classical and PQC private keys live in HSMs; the signing pipeline never sees raw key material. Hybrid signing uses two key handles, one classical, one PQC, both in the HSM.
Vulnerability scanning: every TLS library version surfaces in the inventory; Renovate or Dependabot watches for security releases; PQC-related advisories land in the same review queue.
Network policies: TLS terminators (Envoy, NGINX, BoringSSL) sit behind WAFs that have been audited for hybrid ClientHello handling; legacy middleboxes that drop unknown cipher suites are inventoried and replaced before the rollout reaches their path.
Hybrid signing: classical and PQC signatures are emitted side by side through 2028 minimum; verifiers must succeed on either; CI fails the build if a verifier accepts only one when both are configured.
Scaling and optimization
Horizontal scaling: the crypto-inventory pipeline scales out per repository; one CI job per service is the natural shape. Hybrid TLS at the edge scales with your CDN; the KEM cost is added per handshake, not per byte.
Vertical scaling: Dilithium adds roughly 10% to signing CPU compared to ECDSA; SLH-DSA is roughly 100 times slower. Budget signing throughput accordingly. KEM operations on modern CPUs are fast; the wire size is the bigger concern at high QPS.
Cost optimization: hybrid signing doubles signature size during the migration window; use Falcon for size-sensitive paths (SBOMs, attestations); use Dilithium for throughput-bound paths (per-request signing). HSM cost is procurement; plan refresh cycles years ahead.
Performance tuning: TLS handshake p99 with hybrid KEM is within 5 ms of classical on most stacks; the bottleneck is usually middlebox compatibility, not crypto cost. Audit middleboxes before claiming a baseline.
Failure scenarios and recovery
Static scan misses dynamically loaded crypto (plugins, WebAssembly). Layer runtime scan; dynamic loads show up as TLS fingerprints.
Ownership tag expires and is never re-assigned. Gate PRs that reference untagged assets; force re-assignment.
CBOM format changes between tool versions; downstream consumers break. Pin CBOM version; include in attestation.
When NOT to do this
For small orgs with a single codebase and a single deploy, a quarterly one-shot audit may suffice. At any scale above one team, continuous is the floor.
The thesis
Crypto inventory is a platform service. A one-time project gives you a 2024 answer.
Why this matters now
Meta's crypto inventory (static + runtime scans feeding a tagged asset graph) is the emerging pattern. Every serious org started one in Q1 2026 and nobody has finished.
Narrative arc
Why one-time audits fail → static + runtime dual-scan → the tagging schema (asset, owner, algorithm, rotation cadence) → CI integration so inventory stays live.
What most people believe, and why it falls apart
"We did a crypto audit last year." A point-in-time audit misses every new TLS lib and every new signing path shipped since.
One-shot audits were adequate when crypto libraries were rare. In 2026, every new service ships with TLS; every new build step ships a signature. Inventory has to be continuous to be true.
The timeline
2024-08, NIST standardizes FIPS 203 (ML-KEM), 204 (ML-DSA), 205 (SLH-DSA).
2025-H2, Browser-side hybrid X25519MLKEM768 becomes default in Chrome, Firefox, Safari for TLS 1.3.
2026-04, Meta publishes Post-Quantum Cryptography Migration framework and lessons.
2026-mid, OpenSSL 3.5 ships with production-ready PQC; server-side hybrid rollout unblocks.
2026-09-21, NIST CMVP moves all remaining FIPS 140-2 certificates to Historical status.
2027-01, CNSA 2.0 transition deadline for US National Security Systems begins.
The decision tree, matrix, runbook
Do you run both static (source-scan) and runtime (TLS fingerprint) scans?
Is every asset tagged with owner, algorithm, rotation cadence?
Is your BOM format one of CBOM / CycloneDX 1.6 Crypto / in-toto?
Does the pipeline run in CI, not quarterly?
Is the inventory linked to your platform catalog (Backstage) for ownership?
What to ship this quarter
Deploy a continuous crypto-inventory pipeline in CI.
Add runtime TLS-fingerprint scanning in production.
Emit CBOM per build; tag with owner/algorithm/cadence.
Integrate ownership with Backstage or the platform catalog.
Attest snapshots via Sigstore.
Production observability
Track classical vs hybrid handshake share per edge POP; each POP should hit > 70% hybrid before flipping the default.
Inventory drift on every release; a PR that adds new crypto without an inventory tag fails CI.
Signing throughput monitored; Dilithium adds ~10% over ECDSA; budget for it.
Middlebox handshake-failure rate; a spike at rollout means an unmapped legacy device.
HSM and TPM firmware versions surfaced in the platform catalog; drift triggers a procurement review.
Tech components
CycloneDX Crypto BOM (CBOM) 1.6
OpenSSF CryptoInventory
runtime TLS fingerprinting (ja3/ja4)
Sigstore attestation on inventory snapshots
Backstage Software Catalog extensions
Final word
Post-quantum is a calendar problem. The math is settled, the libraries are real, the deadlines are public. Start the inventory pipeline this quarter, and you will finish the migration on time.
Further reading
Meta Engineering, PQC Migration at Meta (Apr 2026), The inventory pipeline as operated at scale.
CycloneDX 1.6 Crypto BOM specification, The emerging BOM standard.
OWASP Cryptographic Inventory project, the open-source tooling reference.
See references.md for the full bibliography.
