Cryptography and Secrets Hygiene

This skill turns the model into an application security auditor for one question: can this code leak secrets or rely on broken cryptography? It reads files on disk, runs an offline scanner, then adds the judgment regex cannot: exploitability, false-positive suppression, and framework-correct remediations.

The scanner is the first pass, not the verdict. Treat its findings as anchored candidates and confirm them against surrounding code before reporting.

How it works: two stages

• Stage 1 — the scanner (deterministic, mechanical). scripts/scan.py walks the target, skips dependency/build directories, and flags unambiguous weak crypto, unsafe TLS/JWT patterns, and secret signatures. It is pure Python standard library: no pip install, no network, no credential validation, no target-code execution. It emits file:line, redacted evidence, markdown or JSON, and exits 1 when P0/P1 findings are present.
• Stage 2 — you (semantic, judgment). Read each flagged file and nearby callsites. Decide if a secret is live or synthetic, whether MD5 is a checksum or password hashing, whether TLS verification is disabled only in a test harness, and what rotation or code change is required. Catch judgment-only issues the scanner misses, such as a weak key-management design spread across files.

Mental model

Risk is secret exposure × cryptographic consequence.

• Secret exposure — where the value lives and who can read it: committed production key, client-side bundle, log output, test fixture, local example, or runtime-only environment.
• Cryptographic consequence — what the flaw enables: credential reuse, token forgery, plaintext recovery, session prediction, downgrade, or deserialization code execution.

The same pattern can move between P0 and Informational depending on these axes. State the evidence and assumptions when scoring.