Security Pattern Review

Security Pattern Review

Purpose

A guard that catches the textbook case but not its one-token variant is not a weak guard - it is a liability, because it manufactures false assurance while an attacker walks past. The recurring failure mode is authoring a defensive pattern and testing only that it catches the obvious payload, never that a determined attacker can trivially slip around it. This skill makes evasion testing a precondition of shipping: every allowlist, denylist, regex, sanitizer, or guard is attacked against known evasion classes before it ships, and any residual bypass is written down rather than left silent.

When to use this skill

• Before shipping any allowlist, denylist, suppression rule, detection regex, sanitizer, validator, guard, auth check, rate limit, or filter.
• When reviewing someone else's defensive pattern or scanner/linter rule for coverage.
• Whenever the question is "does this rule catch X", "is this pattern safe", or "will this block the attack".
• Before relying on a CI security step or entrypoint guard - confirm it actually runs, don't trust a green check.

When NOT to use this skill

• On patterns with no security or gate-keeping role - a display-formatting regex that fails open harms nothing.
• On throwaway or exploratory matchers the user explicitly asked for rough, that will not ship as a control.
• As a substitute for live-state-truth: reasoning that an input would trip the guard is weaker than running it. If the guard is executable, execute the evasion input against it.

The procedure

Step 1 - State the contract. Write down exactly what the pattern MUST catch (the payloads it exists to stop) and exactly what it MUST allow (the benign inputs it must not break). A guard with no stated allow-set will be tuned into either uselessness or a denial-of-service.

Step 2 - Enumerate the evasion classes for THIS pattern (pick the ones that apply):

• Append-a-token / wrap: put the payload in a table cell, extra pipes, or surrounding markup so a naive "looks like a table" heuristic disables or downgrades the rule.
• Affix bypass (unanchored allowlist): a docs. prefix or github.com. suffix that matches attacker-controlled domains (docs.evil.example, github.com.evil.example) because the match was never boundary-anchored.
• Reorder / multi-stage: the dangerous action split or reordered across a pipeline (curl x | tr ... | sh) so a single-token match misses it.
• Encoding / obfuscation / whitespace: URL/base64/hex encoding, inserted whitespace or comments, homoglyphs, zero-width characters.
• Case: upper/lower/mixed case defeating a case-sensitive match.
• The guard that never runs: a CI step or entrypoint with no __main__ guard, a script that exits before the check, a rule shadowed by an earlier one - it reports green because it never executed.