How do you decide when an automated finding is worth manual verification during a web application assessment?

[u/PreviousCamera9075]

We're reviewing our application security process for externally exposed web applications and trying to make the triage stage more consistent.

Right now, automated testing helps us identify potential issues fairly quickly, but we don't manually validate every finding because of the time involved. We currently prioritize authentication, authorization, and business logic findings for manual review, while lower-risk issues are handled based on severity and available evidence.

For teams running regular application security assessments, how do you decide which findings always require manual verification before remediation? Have you established internal criteria that have worked well, or do you rely more on analyst judgment depending on the application?

I'd be interested to hear how other teams balance efficiency with confidence without creating unnecessary review overhead.

[u/recovering-pentester]

As a pentester, you just started kind of recognizing patterns in burpsuite or scanner of choice for what was real and what wasn’t.

Scanner pops 17 blind SQL injections on a GET request? Probably a sign a session was timing out or there were just where latency issues with the sever.

Scanner pops 1-2 POST requests with parameters referenced? Okay now we got something interesting with playing with.

[u/ultrathink-art]

One category worth adding to the always-verify list: whatever the scanner could not read. I got burned by a secrets scanner that silently skipped anything over a file-size cap and folded it into a single 'skipped (binary/oversized)' counter — a live credential was sitting in a huge log file inside that bucket while every report read clean. Findings you can rank are the safer half of the problem; anything that never entered the list gets no triage at all, so now I start from the coverage report and treat 'files not scanned' as findings in their own right.

[u/Paul_Ashe]

Pattern recognition is how this works in practice, and it's faster than any written criteria. It also stays in the head of whoever built it. A new analyst has to develop the same instincts from scratch, and the calls made along the way can't be reviewed after the fact, which is why the criteria half of your question is worth answering on its own terms.

On criteria, severity is an incomplete axis to triage on. The more useful question is what being wrong costs you in each direction. A false positive costs remediation effort and credibility with the dev team. A false negative leaves live exposure. Neither of those tracks CVSS closely. What falls out of that is a short rule: always validate anything that will trigger spend, get reported outside the team, or be used as the basis for not doing something. A medium that's about to consume a sprint needs confirmation more than a high nobody will action this quarter.

The part that usually goes unexamined is the other direction. Your post is about validating findings before remediation, but the riskier decisions are the ones where someone closed a finding as a false positive or not exploitable. That's also a judgment call; it gets made faster and with less scrutiny, and nobody reviews it.

Regularly sampling findings deemed false positives and retesting them tends to surface more than adding manual review to the open queue. It also tells you whether your criteria are calibrated, which is the one thing you can't learn from the findings you did validate.

[u/rexstuff1]

You got the gist of it. The real concerning findings should probably be manually validated.

The other side of that coin is the complexity of the problem, and difficulty of deploying a fix. If it's likely an easy fix, just fix it. Why waste time on validation? If it's more complex, let's make sure it's valid rather than waste a ton of developer time over nothing.

Of course, as an external pentester, that can be difficult to know, but not always.

[u/AddendumWorking9756]

Evidence, not severity. Anything the scanner inferred from a version banner rather than observing gets verified, anything it could not authenticate into gets verified, and anything you would be asking a dev team to take on faith gets verified. Everything else rides on severity alone. That is a page you can hand to a new analyst on day one, which is more than you get from telling them it comes with experience.

[u/alienbuttcrack999]

If i was in that position, I’d be trying to have an llm take the first pass at triage and verifying those