Analyze Code for Security Vulnerabilities

Evaluates whether APIs, configurations and interfaces resist developer misuse, identifying designs where the "easy path" leads to insecurity. Its core principle is "the pit of success": secure usage should be the path of least resistance, and an API has failed if developers must read documentation carefully or remember special rules to avoid vulnerabilities. It rejects six common rationalizations for footguns: "it's documented" (developers skip docs under deadline pressure - make secure the default), "advanced users need flexibility" (flexibility creates footguns - provide safe high-level APIs and hide primitives), "it's the developer's responsibility" (remove the footgun instead), "nobody would actually do that" (assume maximum developer confusion), "it's just a configuration option" (validate configs and reject dangerous combinations), and "we need backwards compatibility" (deprecate loudly and force migration instead of grandfathering insecure defaults).

It catalogs six sharp-edge categories with detection patterns: algorithm/mode selection footguns (the JWT "alg: none" bypass and RSA/HMAC algorithm-confusion pattern, functions with algorithm/mode/cipher parameters); dangerous defaults (an OTP-lifetime function where lifetime=0 is ambiguous between "never expires" and "expires immediately", plus timeouts, empty strings and booleans that silently disable security); primitive vs. semantic APIs (the libsodium-vs-Halite contrast, where raw-bytes primitives let a caller swap a nonce and a keypair with no type error, versus a semantic wrapper that raises a type error instead); configuration cliffs (a verify_ssl: fasle typo silently accepted as truthy, a session_timeout: -1 magic value, and auth_required: true combined with bypass_auth_for_health_checks: true on health_check_path: "/"); silent failures (a verify_signature that returns True when no key is passed, and verification functions that return a boolean instead of throwing, so a caller can forget to check the result); and stringly-typed security (permissions built as a mutable comma-separated string like "read,write" that can be silently escalated to "read,write,admin", versus a typed permission set). The constant-time-comparison footgun looks identical in code but differs in security property:

if hmac == expected { }           // BAD: timing attack
if hmac.Equal(mac, expected) { }  // Good: constant-time

The analysis workflow runs four phases: surface identification (map security-relevant APIs, developer choice points, and configuration schemas), edge-case probing (what happens with zero/empty/null, negative values, type confusion, defaults, and error paths for each choice point), threat modeling against three adversaries, the Scoundrel who actively controls config, the Lazy Developer who copy-pastes examples, and the Confused Developer who can swap parameters by accident, and validating findings by reproducing the misuse, verifying exploitability, checking documentation, and testing mitigations. Findings are classified into four severities: Critical (default or obvious usage is insecure, e.g. verify: false by default), High (easy misconfiguration breaks security, e.g. an algorithm parameter accepting "none"), Medium (unusual but possible misconfiguration, e.g. a negative timeout with unexpected meaning), and Low (requires deliberate misuse). It closes with an eight-item quality checklist covering edge cases, defaults, algorithm footguns, type confusion, all three adversary types, error paths, configuration validation and constructor-parameter validation.

Use it for reviewing API or library design decisions, auditing configuration schemas for dangerous options, evaluating cryptographic API ergonomics, assessing authentication/authorization interfaces, or reviewing any code that exposes security-relevant choices to developers. Not for implementation bugs (use standard code review), business-logic flaws (use domain-specific analysis), or performance optimization.

Input is the API, library, or configuration schema under review. Output is a list of identified sharp edges, each reproduced with minimal misuse code, checked for real exploitability and mitigation options, and classified as Critical, High, Medium or Low severity.

References its own per-category and per-language reference files rather than a live integration: references/crypto-apis.md, references/config-patterns.md, references/auth-patterns.md, references/case-studies.md (OpenSSL, GMP and other real-world examples), and per-language footgun guides for C/C++, Go, Rust, Swift, Java, Kotlin, C#, PHP, JavaScript/TypeScript, Python and Ruby.

Security reviewers and API or library designers auditing cryptographic, authentication, authorization or configuration interfaces for designs that make insecure usage the easy path.