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.
No sales call required to get a number. Start free, scale as your repository count grows, and see exactly what changes at each tier.
Cryptography accumulates quietly: an old library here, a half-finished migration there, a config file nobody's revisited in years. Ask most security teams for a complete, current picture of every algorithm running across their systems, and the honest answer is that no one fully has one.
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.
Continuous visibility replaces guesswork with clarity — so you can move toward the post-quantum transition with confidence, not uncertainty.
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. It's deliberately blind to everything except "does this line match a known-weak or known-safe primitive."
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.
A ZK proof establishes that a specific, already-identified statement holds — it can't discover a vulnerability nobody has named yet. So zkAssess splits the problem into the two shapes each technique actually handles.
A deterministic scanner checks every line against a fixed, versioned list of known-bad and known-good cryptographic patterns. This needs full visibility, so it stays inside your trust boundary — local, in CI, or inside a TEE.
Once a finding exists, "this exact redacted line is really present in a file with hash H, at line N" is precisely the narrow, provable statement that selective-disclosure techniques are built for.
"This codebase uses RSA" is checkable. "This codebase is insecure" isn't — it's an unbounded judgment call. zkAssess keeps the provable part of the pipeline entirely deterministic: regex and syntax matching against a public, versioned pattern list.
| 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 |
The baseline score is simple and public: findings are weighted by severity, summed, and subtracted from 100. Because the formula and weights are versioned alongside the pattern set, any verifier can recompute the same number from the same inputs.
No single formula reflects every organization's risk tolerance. A payments company may need any broken cipher to be an automatic failure; a government contractor may need quantum-vulnerable findings weighted well above everything else. zkAssess makes the weighting function itself a declared, versioned input — it travels with the attestation, so a policy can never be quietly loosened after the fact.
Table 4 default weights. No category multipliers.
Any classically-weak cipher is an automatic failure. ECB mode and static IVs weighted above baseline.
Balanced weighting across weak and quantum-vulnerable categories; emphasis on config weaknesses common in legacy health-record systems.
Quantum-vulnerable multiplier raised well above baseline. Quantum-safe bonus enabled to track migration progress.
Lower overall weights, no automatic-failure thresholds — visibility and trend-tracking over a hard gate.
A finding is recorded with only a bounded window of context around the matched text — by default twenty characters on either side. Every other line in the file is hashed into a Merkle tree and never retained. A verifier can confirm a flagged line is genuinely part of a file with a given hash, without ever receiving the file.
A true zero-knowledge circuit would go further than what the current reference implementation does. We'd rather tell you where the line sits today than overstate it.
Traditional code security audits are priced around expensive things: consultant hours, manual review, and the liability of a third party holding your source. Remove those, and the price changes.
The same deterministic pattern engine runs across every language and framework your findings cover — no per-vendor tooling to stitch together for different parts of the stack.
Your code never leaves your boundary, so there's no data-handling insurance, no breach liability, and no custody chain to price into the bill the way a traditional third-party scanner has to.
A versioned, public pattern set does the work a human auditor would otherwise bill hours for — reproducible by anyone, not billed by the hour.
We'd rather list what genuinely holds than borrow a badge. Here's what's real about zkAssess right now:
Replace the Merkle inclusion proof with a circuit that proves a pattern match exists in a committed file without revealing the line's content or position at all.
Independent attestor nodes, selected through an auction mechanism with economic staking, remove the need to trust any single signer.
A split-trust architecture across two Trusted Execution Environments, for cases where even the repository owner's own infrastructure shouldn't see plaintext.
ML-DSA (Dilithium) as an alternative to HMAC-SHA256 for public, many-verifier attestations — keeping the protocol's own signatures quantum-resistant end to end.
TLS and ciphersuite configuration scanning, dependency-manifest checks for known-vulnerable packages, and AST-based matching to cut false positives and negatives.
# .github/workflows/zkassess.yml steps: - uses: collatzlabs/zkassess-action@v1 with: policy: 'nist-cnsa-2.0' fail-below: '70' # Output: signed attestation, posted to the PR # score: 82/100 · pattern_set_version: 2026.07.1
Run the analysis inside your own boundary. Share only what a verifier needs to trust the result.