Deep Scan

The Question

Why does every website security scanner hand you a hundred "vulnerabilities" and leave you to work out which three are real?

I built the first version of this to hunt novel bugs in smart contracts, using an LLM to reason about code the way a human researcher would. It didn't hold up. Too much of what it flagged wasn't real, and against contests where I could check what actually got paid out, the hit rate wasn't there. I killed that version and rebuilt around a much narrower promise.

What I Built

Deep Scan runs the pipeline a bug bounty hunter would — recon, then fuzzing, then scanning with the tools the security industry actually trusts: Nuclei, ffuf, sqlmap, and others. Then the part I actually care about: a confirmation stage that tries to prove a finding is real before it goes anywhere near a client. SQL injection, XSS, SSRF, RCE, LFI — named and confirmed, or not reported at all. No CVSS-scored theory, no padding a report with "this header is technically missing" to make it look thorough.

What I Learned

Web security turned out to be a different problem wearing the same clothes as the one I'd killed. Almost nothing about a SQL injection or an exposed API endpoint is novel — it's the same twenty-odd vulnerability classes, over and over, and there's already excellent deterministic tooling that finds them. What was missing wasn't detection. It was someone willing to confirm a finding before putting their name on it. That part I still do myself, on every scan, before a client sees it.

Status

Live at autoalpha-sec.com, under the Auto Alpha Security brand. I review every confirmed finding myself before a client sees it.