Accuracy notes — real-repository audits¶
v0.2.0 audit (2026-07-14): three public repositories¶
Depth-1 clones of three deliberately different public projects, scanned with all detectors, sample of P0/P1 findings hand-verified against each project's known design.
| Repo | Findings | Score | What Lattice saw | Hand-check verdict |
|---|---|---|---|---|
paramiko/paramiko (Python SSH) |
43 (13 P0) | 54 | ECDSA/ECDH/RSA/AES kex+hostkeys, SHA-1 in host hashing, MD5 fingerprints, bcrypt KDF | All spot-checked matches real (e.g. kex_curve25519.py:30 X25519 keygen, config.py:449 sha1) |
FiloSottile/age (Go encryption) |
30 (9 P0) | 62 | ChaCha20-Poly1305 ×8, X25519 ×5, scrypt, HMAC — exactly age's published design; RSA from ssh-rsa recipient support | Matches the project's documented cryptography precisely; the RSA private key in .github/workflows/certs reported location-only, body not read |
auth0/node-jsonwebtoken (JS JWT) |
25 (12 P0) | 26 | RSA ×11 / ECDSA ×7 (RS256/ES256), SHA-1-signed test certificates via the DER parser | Real matches; note below on signature-usage conservatism |
Known conservative behaviors observed (kept deliberately, documented):
- Signature-context blindness in JS:
generateKeyPair('rsa')in a JWT library is signature usage (P1-appropriate), but the call site alone cannot prove that, so RSA defaults to key-establishment scoring (P0, HNDL). Java'sSignature.getInstanceand certificates do pin signature usage; bare keygen does not. - Hash-usage blindness: paramiko's
sha1()in known-hosts hashing is an HMAC-SHA1 construction (collision resistance not load-bearing), still reported P0 as collision-broken SHA-1. Static analysis cannot see the construction; the justification string states exactly which property is broken so a reviewer can triage. - Test material counts: certificates and keys under
test/directories are real findings at real locations; use--exclude "test/*"or alattice.tomlacceptance when they are noise.
No crashes, no unreadable-file failures, deterministic output across repeat runs on all three repos.
v0.1.0 audit — CPython standard library¶
Record of the Phase 6 false-positive tuning pass required by the execution plan. These are observations from real runs, not benchmarks; no detection rates are claimed because no ground-truth corpus exists for these targets.
Targets¶
- CPython 3.11 standard library (
Lib/, ~5,800 files, scanned in ~72 s on one Windows machine — treat as an order of magnitude, not a benchmark). - The Lattice repository itself (dogfood run; 54 files).
Both runs completed without crashes or skipped-file errors.
Observations (stdlib run: 173 findings — 58 P0, 17 P1, 49 P2, 8 P3, 41 compliant)¶
True positives verified by hand (sample):
- poplib.py — MD5 (the APOP protocol genuinely uses MD5).
- antigravity.py — MD5 (geohash implementation).
- test/certdata/*.pem — RSA keys and SHA-1-signed test certificates,
correctly extracted from real PEM/DER material.
False-positive characteristics found (and kept, deliberately):
- Scanning a codebase that implements or tests TLS (like the stdlib's
ssl module and its test suite) flags the protocol constants it defines
and exercises (30× SSL-3.0, 30× TLS-1.0 findings, mostly in test/).
These are real matches of real constants, but "this repo tests SSLv3"
is different from "this service enables SSLv3". Lattice cannot tell the
difference statically; the findings stay, honestly located, and the
reader decides. Excluding test trees with --exclude "test/*" is the
practical mitigation.
- UNKNOWN key-material findings (14×) are presence-only reports for
certs/keys that did not parse cleanly — by design they carry no risk
grade.
Confidence distribution: 171/173 high, 2 low. The stdlib is Python + PEM, which are the two highest-confidence detectors (AST and DER parse). Regex-heavy targets (Java/JS/C) will skew lower; their fixtures encode the expected confidence levels.
Not tuned: no per-repo suppressions were added. The knowledge base remains the single source of truth; the only tuning outcome of this audit was confirming that directive-anchored config matching (rather than free-text matching) keeps config false positives near zero.