Cryptographic inventory

The cryptographic inventory, with the evidence behind every row

Every service, database, image, endpoint and library in one place: the algorithm, the key length, the system it belongs to, and the person who owns the fix. Built from your own estate rather than from a survey of what teams remember.

The cryptographic inventory in the readiness workbench: risk counts, a breakdown chart and a table of assets by algorithm, application, evidence, wave and status.

A real capture of the cryptographic inventory, populated with a sample estate.

What it records

Four fields, and the fourth is the hard one

Algorithm and key length come from reading the estate. System and owner come from your organisation. Only the first two can be automated, and pretending otherwise is how inventories go stale.

FieldWhere it comes fromWhy it matters
AlgorithmRead from source, build artifacts, images, cloud configuration and the TLS handshakeRSA, ECDSA, SHA-1 and the post-quantum replacements already in use, classified against the quantum model
Key lengthRead where the code declares it, including through variables and configurationA 1024-bit key and a 4096-bit key are not the same exposure, and neither is a hybrid
SystemThe application, deployment, environment and asset a finding belongs toSo the inventory answers "which system?" and not only "which file?"
OwnerSet once in the workbench and carried into every report, wave and evidence packAn unassigned finding is visible as unassigned, rather than quietly disappearing into a backlog
Where it comes from

One inventory, not five

Your code

22 language families, 11 of them parsed rather than pattern-matched, so a key size passed through a variable is still read.

Build artifacts and images

JAR, WAR, wheel, package and container layers. The OpenSSL that breaks the story usually arrives in a base image, not in a repository.

Cloud and endpoints

Keys, vaults and TLS policy from configuration, plus a real TLS handshake against public endpoints rather than trusting a header.

Existing scanners

Import CycloneDX CBOM output from the tools you already run, so the result is one inventory rather than five spreadsheets.

Ownership

Fill in the owner and the system once. Later scans of the same scope attach themselves to the same application.

Exports

CSV, JSON, CycloneDX CBOM and SARIF. The inventory is the artefact a customer or an auditor asks to see.

How it is used

From the inventory to the plan

Applications in the plan, each with a repository scope, impact and likelihood.
Applications group the inventory by what you actually run.
Migration waves one, two and three, with the inventory items assigned to each.
Every item is assigned to a wave, so the inventory becomes a schedule.

What it does not do

It does not connect to your databases, read business records, or certify that you are compliant. The inventory is evidence, and your attestation is yours. It also states what it could not see: an inventory that implies full coverage is worse than one that names its limits.