Anyone who has run a traditional vulnerability scanner knows the ritual: kick off the scan, come back to four hundred findings, and spend the next two days deleting the ones that aren't real. Most scanners optimise for not missing anything, which is a polite way of saying they flag everything that pattern-matches and leave the verification to you. That inverted workload — the tool does the easy part, the human does the hard part — is the problem I built SentryScan to fix. Its whole design philosophy is one line: find it, prove it, report it.
The false-positive tax
A finding you can't trust is a finding you have to re-verify by hand. When a scanner says "possible SQL injection here", that "possible" is doing enormous work — it's really saying "a response pattern loosely matched; you go confirm it." Multiply that across hundreds of low-confidence flags and the tool has, in effect, generated your homework rather than done your work. Teams learn to distrust scanner output entirely, which is worse than no scanner: real bugs drown in the noise and get dismissed along with the false ones.
The fix isn't a better pattern. It's a different bar for what counts as a finding.
Prove it or don't report it
SentryScan's core principle is that a finding should be actively demonstrated, not merely suspected. Rather than flagging a response that looks like it might be injectable, it attempts to non-destructively reconstruct the exploitable condition and confirm the vulnerability actually behaves the way the signature suggested. If it can prove the issue, it reports it with the evidence and reproduction steps. If it can't, that candidate doesn't clutter your report. The output is a short list of things that are real, each with the proof attached — not a long list of things that might be real.
This flips the workload back the right way round: the tool does the tedious verification, and the human spends their attention on the findings that need reasoning.
What it covers
SentryScan runs 64 detection modules across six categories, mapped to the OWASP Top 10:
- Injection & XSS — SQL injection (error-based, blind, time-based, header, auth-bypass variants), reflected and DOM XSS, LFI, SSTI, NoSQL and CRLF — driven from a JavaScript-aware crawl so it actually reaches modern single-page apps.
- Misconfiguration & exposure — security headers, CORS, clickjacking, open redirect, cache poisoning, and source leaks like exposed
.gitand.env. - API & auth — Swagger/OpenAPI exposure, GraphQL introspection, JWT weaknesses, and full authenticated scanning for SPAs.
- Plus attack-surface mapping and integration with the wider tooling ecosystem (Nuclei's 10k+ templates, and the standard offensive toolchain) so coverage is broad without sacrificing the proof-based bar.
The optional AI triage pass
For borderline cases — the genuinely ambiguous ones that sit right at the confidence threshold — there's an optional AI pass that double-checks the candidate before it reaches your report. It's not the primary detection mechanism (proof-based verification is), it's a second reviewer that pushes false positives even closer to zero on the hard cases. Detection stays deterministic; the AI is a filter on the margin, not the judge.
Built for authorized testing only
This matters and it's enforced in the architecture, not just the docs. Every scan confirms authorization, and scope is enforced centrally so a check cannot reach a host you didn't explicitly put in scope. It's a tool for testing systems you own or have written permission to test — the same ethic that governs every engagement I run. A scanner that could be pointed anywhere is a liability; one that structurally refuses to leave its scope is a professional instrument.
Why this connects to how I test
Everything I've written about — chaining an IDOR into account takeover, business logic flaws, the API security checklist — shares one theme: the high-value findings come from reasoning about impact, not from pattern-matching. A scanner can't reason about whether a leaked field means account takeover. What it can do is take the mechanical, verifiable findings off my plate — prove them, evidence them, and hand me a clean list — so my human time goes where automation can't follow. SentryScan is that division of labour turned into a tool: let the machine prove the provable, so the tester can hunt the rest.
You can read the full breakdown of modules, coverage and how it fits an engagement on the SentryScan page. It's a product I'm actively building; if that approach to scanning is useful to your team, reach out about early access.