vibe-audit.workshop

guides · 2026-10-11

What Code Scanners Can't Find

We build a code scanner, so here's something our marketing department would never let us say if we had one: automated scanning is necessary and insufficient. A clean scan is not a clean bill of health. Here's an honest map of what scanners can and can't find — and how to cover the gaps.

What scanners are genuinely good at

Scanners excel at known patterns at scale: hardcoded secrets, SQL string concatenation, innerHTML sinks, missing security headers, exposed .env files, outdated dependencies with CVEs. These are high-frequency, well-defined, and boring — exactly the work humans skip and machines don't. A scanner will check ten thousand lines for these patterns in seconds, the same way every time. That consistency is the value proposition.

1. Business-logic flaws

A scanner sees if (user.isPremium) applyDiscount(50) and moves on — it can't know the discount was supposed to be 5%, or that isPremium can be set client-side. Business logic lives in your head and your spec docs, not in the code's syntax. Coupon stacking, negative-quantity purchases, trial resets, referral fraud — these are the vulnerabilities that cost real money, and no pattern-matcher finds them. Only someone who understands what the code is supposed to do can spot what it shouldn't do.

2. Broken access control in context

Scanners can flag a route with no auth middleware. They struggle with the subtler kind: the middleware exists but checks the wrong thing, or the ownership check covers reads but not deletes, or the admin check runs on the frontend while the API trusts the client. Authorization is a property of the whole system's intent — "can user A touch object B?" — and answering it requires understanding your data model, not just your syntax tree.

3. Novel attack chains

Scanners know yesterday's attacks. Chained exploits — an XSS that plants a payload the admin panel later renders, a race condition between balance check and withdrawal, a second-order injection where input is stored safely but executed unsafely elsewhere — cross file and time boundaries that pattern matching doesn't. Taint tracking helps (following untrusted input to dangerous sinks), but multi-step chains with human-scale reasoning still need human reviewers or dedicated penetration testing.

4. Cryptographic design errors

A scanner can flag MD5 or hardcoded IVs. It can't tell you your custom "encrypt then MAC, but verify the MAC never" protocol is broken, or that your key-derivation parameters are too weak for your threat model, or that your randomness source is fine but your token lifetime is forever. Crypto fails at the design level, and design review is a human specialty.

5. AI-specific failure modes

The newest blind spot: prompt injection in your AI features, training-data leakage through your chatbot, insecure tool-calling in your agents. Most code scanners were built before these existed and don't model them. If you ship AI features, you need AI-specific testing — red-teaming your prompts and agents, not just scanning the code around them.

What "defense in depth" actually means

The honest security stack for an AI-assisted team:

  1. Constrained generation: prompts that specify security requirements up front.
  2. Automated scanning: every change scanned before merge — the fast, consistent first pass. (This is the layer Vibe-Code Audit provides: secrets, injection, XSS, headers, dependency verification.)
  3. Human review of the seams: auth logic, data flow, crypto choices — reviewed by someone who understands the system's intent.
  4. Periodic penetration testing: for anything handling money, health data, or real user trust — humans attacking the running system, not just the code.
  5. Runtime defenses: WAFs, rate limits, monitoring and alerting — because some attacks only exist in production.

Why we're telling you this

Because trust is the product. A scanner vendor that claims to find everything is selling certainty it can't deliver — and the day a customer gets breached through a logic flaw we never claimed to catch, that lie costs more than the subscription was ever worth. Use scanners for what they're brilliant at, humans for what they're not, and never confuse a 100/100 score with invulnerability. The score measures the patterns we check. Security is bigger than the checklist.


Informational explainer, not a security guarantee. Scan your code free before every deploy.

← all guides