Skip to content
All articles
Research

From a snapshot to a signal: continuous post-quantum posture

By quantakrypto Research3 min read

Also mentioned

NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab), CBOMCBOMcryptographic bill of materialsA Cryptographic Bill of Materials, a structured, machine-readable inventory of the cryptographic assets used by a system or application, often expressed as an extension of a software bill of materials (SBOM).Read the full entry (new tab) are defined in the glossary.

TL;DR

Read this first

A scan is a photograph; a migration is a film. We now record the film. Every completed scan writes an append-only posture snapshot (readiness score plus finding counts), we diff it against the previous run by a stable finding fingerprint that ignores line shifts, and a drift alert fires the moment a change reintroduces quantum-vulnerable cryptography. Findings group into migration projects with owners and status, and an item closes itself when its fingerprint disappears from a later scan.

Every competitor sells a snapshot. An organization in the middle of a multi-year migration needs the opposite: the trend. Is the vulnerable surface shrinking? Did last week's pull request quietly reintroduce an elliptic-curve handshake you had already retired? Which of the 400 findings belong to which workstream, and who owns them? A single scan cannot answer any of that, because identity across scans is the hard part. That is the gap we closed.

The identity that survives a line shift

The unglamorous prerequisite for a trend is a stable name for a finding. A raw finding is positional (rule, file, line, message), so a single added import at the top of a file shifts every line below it and a naive diff reads the whole file as resolved-and-reintroduced. Our scanner now emits a fingerprint on every finding: a hash of the rule id, the normalized repository-relative path, and a normalized snippet of the surrounding code, with the volatile line number deliberately excluded. It is the same identity the baseline already used, now surfaced in both the JSON output and the SARIF properties, so a line move does not change it and downstream tools can key on it.

Snapshots and drift

When a scan completes, we write one append-only posture snapshot: the score, the finding totals by severity, and the set of fingerprints that appeared (new) or disappeared (resolved) versus the previous snapshot of the same check. When new fingerprints appear and a baseline existed to compare against, a drift alert is raised and the people tracking that repository are emailed. The rule is deliberately conservative, because an alert that cries wolf kills the feature:

  • A snapshot records score, severity-weighted counts, and the new and resolved fingerprint sets, keyed to the scan run so a re-delivered result is idempotent.
  • A drift alert fires only when a completed run introduces fingerprints that were not in the previous run, mirroring the GitHub Action's fail-only-on-new discipline.
  • A repository's first snapshot never alerts (there is nothing to compare against), so onboarding a repo is silent.

Migration projects, not spreadsheets

Findings become work when they are grouped, owned, and tracked. A migration project is a named, statused grouping of findings for a repository (or org-wide), and you populate it by bulk-assigning straight from the cryptographic inventory. Each item carries a status and an owner. The important part is that a human does not close items: when an item's fingerprint stops appearing in a later snapshot, the scanner marks it migrated automatically. The tool that found the problem is the tool that confirms the fix.

The whole org at a glance

The same substrate rolls up. An org view aggregates the latest posture across every tracked repository, a combined score-and-findings trend, open drift, and migration status, with a per-repository drill-in. It is the same measurement the public PQC Observatory performs against the open web, turned inward and made continuous for the systems you actually own.

A snapshot tells you where things stand. A series tells you which way they are moving, and direction is the only thing that lets you plan.

Migration timelines are driven by evidence, not exhortation. A number that moves, that you can watch and question, does more to fund and finish a migration than any single audit report. The photograph was never the point. The film is. Start with a scan: npx @quantakrypto/qscan ./

References

Get started

Turn quantum risk into a credential.

Book a discovery call and get an indicative scope and pricing for your organisation.