Cryptographic bill of materials
You cannot migrate what you have not inventoried
Stella Ops analyzes the cryptographic assets declared in a CycloneDX CBOM — algorithms, keys, certificates, protocol configurations — and assesses how ready each one is for post-quantum migration.
Analysis covers declared assets. What the CBOM does not declare, Stella does not guess.
What a CBOM is
A CBOM is the cryptographic counterpart of a software bill of materials: a structured inventory of the algorithms, key sizes, certificates, and protocol versions a piece of software uses. CycloneDX records it in cryptoProperties on the components of an SBOM. CycloneDXAn open standard format for software bill of materials (SBOM) used across the industry SBOMSoftware Bill of Materials - a complete list of all packages and dependencies in your software
When a scanned SBOM declares cryptoProperties, the scanner runs a crypto-analysis stage and attaches the report to the scan evidence. Crypto findings enter the same custody chain as vulnerability findings — recorded, linkable, replayable.
What the analysis covers
Five checks run over the declared cryptographic assets. Each produces findings tied to specific assets, not a single pass/fail grade.
Weak and deprecated algorithms are detected against a maintained catalog: short keys, retired hash functions, deprecated protocol versions.
Shows which assets rely on quantum-vulnerable primitives and where migration effort concentrates, so a migration plan starts from evidence rather than estimates.
Assessment only. Stella Ops does not perform post-quantum signing.
Validates declared assets against FIPS 140-2/3, PCI-DSS, and NIST cryptographic policies, plus regional crypto profile checks.
Validation reports findings; it does not certify compliance. Evidence is collected in conservative evidence-only mode, and the operator always remains the regulated decision-maker.
Generates an inventory of the cryptographic assets declared for the scanned artifact — the baseline document a migration programme starts from. Undeclared assets are absent from the inventory, not inferred.
X.509 certificate analysis and TLS protocol-version analysis: expiry, weak signature algorithms, and deprecated protocol versions, reported per asset.
Why now
Post-quantum migration has moved from research papers to project plans. The facts, without alarm:
NIST published its first post-quantum cryptography standards in August 2024 (FIPS 203, 204, and 205). The target algorithms are no longer a moving target.
Migration planning now appears in security roadmaps and 2026 budgets. The planning question is scope: which systems use quantum-vulnerable cryptography, and where.
Every migration programme starts by answering the same question: what cryptography do we run today? A CBOM inventory answers it from scan evidence rather than a spreadsheet survey.
How it fits the custody spine
Where the evidence attaches
- Source
- Build
- Scan
- Verdict
- Decision
- Deploy
- Watch
CBOM evidence attaches at the Scan stage, alongside vulnerability and SBOM evidence. From there it follows the same path as every other finding: policy can gate on crypto findings at Verdict, and the decision that ships carries the crypto evidence with it.
Same chain, same replay: a crypto finding can be re-derived deterministically from the recorded inputs.
Related
How the platform itself signs, verifies, and stores evidence — distinct from analyzing your software's cryptography.
The software inventory the CBOM extends: CycloneDX and SPDX generation, VEX statements, and how both feed verdicts.
Where crypto findings can feed evidence collection for regulatory frameworks, in evidence-only mode.