The Vulnerability the Scanner Didn't Find
Lou Vega leads application and product pen testing at VDA Labs and co-founded the Charleston Infosec Group. The talk grew out of a single client email asking which Burp Suite configuration he used to find a particular vulnerability. The honest answer was none — he saw something weird in the app, traced it down, and exploited it. That mismatch between what scanners can find and what humans notice is the whole talk.
Why Push-Button Scanning Fails
Lou is careful not to bash automation. Burp, ZAP, static code analyzers, AI-assisted tools — they all crush low-hanging fruit and they all keep getting better. But they're fundamentally backward-looking, like the old monthly antivirus signatures. Point any of them at OWASP Juice Shop, an app deliberately stuffed with vulnerabilities, and they'll find a handful and miss the rest. Source-code scanners flag patterns that turn out to be unexploitable, and miss real injection points elsewhere in the same codebase. Add alert fatigue, evolving attack surface, third-party libraries, and the cultural dysfunction of security teams throwing reports over the wall, and a tools-only program produces busy work, not security.
The Curiosity Workflow
Lou's process is simple to describe and hard to internalize. Look for the weird — what's that odd response, what caused it, can you reproduce it? Get curious — what assumptions is the developer making, what happens if you violate them? On a forgot-password form, what if you put two email addresses comma-separated? He has found apps where the reset went to both. Try things quickly and iteratively. Every user-controllable input is a potential code-execution vector. Connect the dots — chain small findings into a real impact. Then show your work, because you're paid for the report, not for the hack.
Tips for Getting Weird
Verbose error messages are a gift to attackers. Hidden inputs — custom cookies, JavaScript that the UI never exposes — are often where the unsanitized parsing lives. Play with state, timing, and race conditions. Lou's war stories include a textbook SQL injection on a sheriff's office login (single-quote-or-1-equals-1 in the password field), an admin=true cookie that just worked, and a banking app with one injectable field hiding among 160 on a mortgage form. The most memorable was a user-creation flow that ran the license check after creating the user — the create succeeded, the license failed, and the orphaned ghost user could still authenticate.
What Both Sides Can Do
For organizations: schedule curiosity time, even two hours a week, for someone to look at the app from outside the user story. Stop demanding outsider-only black-box tests on a two-week clock — real outsiders have unlimited time, and a scoped grey-box test gets you more coverage for the same money. Rotate fresh eyes onto the codebase. Capture the weird in your own internal dictionary of anomalies. For ethical hackers: understand how the app is supposed to work before attacking it. Sit in on storyboarding when you can. Communicate every two or three days during the engagement — wins as well as findings, because clients almost never hear positives from security people.
Who Should Watch
Application security testers at any level, especially anyone whose program leans heavily on automated scanning. Developers who want to internalize an attacker's reading of their own code. Security leaders trying to figure out why two pen tests on the same app produced wildly different reports.