zkAssess scans your codebase for quantum-vulnerable and classically weak cryptography, then issues a signed, cryptographically committed attestation. The analysis runs entirely inside your trust boundary — only a redacted score ever leaves it.
zkAssess surfaces the quantum-vulnerable and classically weak cryptography that's already running in production — the risk you can't fix because no one's found it yet.
Findings across every repository and service are pulled into a single, reproducible inventory — not a pile of disconnected scan results nobody has time to reconcile.
Deterministic, versioned pattern matching replaces manual code review and best-guess audits with something any verifier can reproduce.
Run zkAssess in CI on every commit, and your cryptographic inventory stays current instead of going stale the moment something changes.
zkAssess doesn't upload your repository, doesn't cache your source, and doesn't retain a copy anywhere on our side — because it never runs on our side. The scanner executes entirely inside your machine, your CI runner, or your TEE. The only thing that ever reaches us is a signed, redacted attestation: a score, which pattern IDs matched, and a cryptographic proof that each finding is real.
We can't leak what we never had. That's not a policy promise — it's the architecture.
The pattern engine doesn't read your business logic, your comments, or your architecture to understand what your product does — it only matches lines against a fixed, versioned list of known cryptographic patterns.
Once that blind scan produces findings, that's where your company enters the picture: your scoring policy, your compliance profile, your risk tolerance decide what the findings mean and what happens next — never the other way around.
Finding a problem in your code means actually reading the code — there's no way around that. So that part happens privately, on your own machine. Once something is found, we only need to prove that one specific thing is real — like showing a notarized receipt instead of your whole bank statement.
A scanner checks every line of your code against a public list of known-risky and known-safe patterns. This step needs to see everything, so it never leaves your computer, your CI pipeline, or your own secure environment.
For each thing found, we generate a small, provable receipt — "this exact (redacted) line really exists at this file and line number." That receipt is mathematically checkable without ever showing anyone the file itself.
"This codebase uses RSA" is a fact you can check. "This codebase is insecure" is a judgment call. zkAssess sticks to the checkable part: matching code against a public, versioned list — nothing guessed, nothing subjective.
| Category | Examples | Why it matters |
|---|---|---|
| QUANTUM-VULNERABLE | RSA, ECDSA / ECDH / EdDSA and named curves, Diffie-Hellman, DSA | Breakable by Shor's algorithm on a sufficiently large quantum computer |
| CLASSICALLY WEAK | MD5, SHA-1, DES, 3DES, RC4, RC2 | Already broken or impractically weak, independent of quantum computing |
| CONFIGURATION | ECB mode, RSA keys under 2048 bits, static IVs / salts | The primitive may be sound but the usage pattern undermines it |
| QUANTUM-SAFE | AES-256, ChaCha20-Poly1305, SHA-256/3, BLAKE2/3, ML-KEM, ML-DSA, SLH-DSA, Falcon | Positive confirmation of already-good cryptographic hygiene |
This is the whole privacy design in one sentence: keep a tiny, bounded snippet per finding, replace everything else with an unreadable fingerprint, and let that fingerprint be checked mathematically — never by handing over the file.
zkAssess is deterministic pattern matching — it tells you what cryptography exists and where. It doesn't evaluate whether your protocol architecture is sound, whether your threat model is tight, or whether an implementation faithfully realizes its design. For that, engagements are led by a senior cryptography expert, not a scanner report.
Key exchange, authentication flows, session management, state machines. We evaluate the architecture before the first line of implementation code.
Are the chosen primitives appropriate for the threat model? Do they compose correctly? AEAD, KDF, signature, KEM — every choice scrutinized.
What did the design assume the adversary can do? Are those assumptions tight? AI bug-finders cannot challenge threat models — humans must.
Does the code correctly realize the design? Go, Rust, TypeScript, Swift, Java, .NET, C, Solidity. Full-source audits, not scanner reports.
Is your system positioned to survive the next decade of cryptanalytic advances? KEM hybridisation, signature strategy, library and protocol fitness.
Symbolic verification of protocol correctness in Verifpal, ProVerif, or Tamarin — and critical review of formal-verification claims others have made about code you depend on.
No sales call required to get a number. Start free, scale as your repository count grows, and see exactly what changes at each tier.
Run the analysis inside your own boundary. Share only what a verifier needs to trust the result.