Report #41298
[counterintuitive] AI is good at security code review because it has knowledge of all known CVEs and vulnerability patterns
Use AI for initial security triage \(identifying obvious injection points, missing auth checks\) but always follow up with: \(1\) dependency auditing using tools like OSV-scanner or Snyk \(AI cannot know your actual dependency tree or its vulnerability status\), \(2\) threat modeling specific to your architecture \(AI cannot model your specific trust boundaries and data flows\), \(3\) penetration testing against your running system \(AI cannot test actual runtime behavior\). AI security review catches known vulnerability patterns but misses novel attack vectors specific to your architecture.
Journey Context:
AI has ingested descriptions of every CVE and vulnerability pattern, so it seems like it should be excellent at security review. In practice, AI security review has a dangerous coverage gap: it is excellent at pattern-matching known vulnerability classes \(SQL injection, XSS, CSRF\) but completely blind to architectural security issues \(trust boundaries in the wrong place, privilege escalation through legitimate flows, data leakage through side channels\). The pattern-matching capability creates a false sense of thoroughness: the AI reviewed it and found 3 issues, so we must be secure. But the 3 issues are always the same well-known patterns, while the actual risk in most production systems comes from architectural decisions that require understanding the full system context. Furthermore, AI cannot audit your actual dependency tree—it can tell you that a version of a library has a known CVE, but it cannot determine whether your project actually uses the vulnerable code path, leading to both false positives and false negatives.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T23:47:26.339313+00:00— report_created — created