What Separates a Written Finding From a Scanner Alert

The clearest way to tell what you paid for is to look at a single finding and ask what it would have looked like if a tool had produced it.

Below is a genuine access-control finding as it appears in a published sample report, set against the same underlying issue as automated tooling typically surfaces it.

As a scanner reports it

[MEDIUM] Possible Insecure Direct Object Reference
URL:        /api/users/{id}
Parameter:  id
Confidence: Medium
Description: The application may expose internal object
             identifiers. Verify that access control is
             enforced.
Remediation: Implement proper access control checks.

This is not useless. It points at the right endpoint and names the right category. But notice what a developer receiving it does not know: whether it is real, what happens if it is, and what specifically to change.

Notice also the words possible, may and verify. The tool is reporting a pattern it matched, and handing the actual question back to you.

As a tester writes it

F-001: Broken Access Control — Horizontal Privilege
       Escalation via Insecure API
CVSS v3.1: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: 285    OWASP: A01:2021

The endpoint fails to verify that the authenticated user owns the requested resource. An attacker authenticated as any valid user can access the profile data of any other user by enumerating user identifiers.

Remediation: implement ownership verification — check that the authenticated user's identifier matches the requested one before returning data. Deny by default; explicitly allow only the owning user and designated administrative roles.

Accompanied by the request that demonstrated it, the response containing another user's data, and the affected endpoints listed individually.

The six differences

1. Confirmed, not suspected

"Possible" became demonstrated. Somebody sent the request, received another user's data, and captured it. Everything downstream depends on this: you cannot sensibly prioritise a maybe, and you cannot confirm a fix for something never shown to be broken.

2. Severity that reflects reality

Medium became 9.8. The scanner hedged because it could not tell whether the identifier was protected. The tester established that it was not, and that any authenticated user could read any other user's data — which is a critical outcome, not a moderate one.

This error runs in the other direction just as often. Scanners routinely report high-severity issues that are unreachable in practice, and triage means demoting those too.

3. Mechanism, not category

"May expose internal object identifiers" names a class. "Fails to verify that the authenticated user owns the requested resource" names the defect. A developer can act on the second immediately; the first requires them to investigate from scratch.

4. Remediation you can implement

"Implement proper access control checks" restates the problem as an instruction. The written version says what to check, where, and what the default should be — deny by default, allow the owner and designated administrative roles explicitly. That is a code change somebody can make this afternoon.

5. Impact stated in terms of consequence

The written finding says what an attacker reaches: the profile data of any other user, by enumeration. That sentence is what lets you decide how quickly this needs to be fixed, and it is what a regulator or a customer will ask about.

6. Classification that connects

CWE-285 and OWASP A01:2021 place the finding in a taxonomy — which links it to published guidance, and makes it visible when several findings share a class and the real problem is a pattern rather than an instance.

What this does not mean

It does not mean the scanner was wrong to raise it. Automated tooling found the right endpoint, and on a large surface it will do that across thousands of candidates faster than any person. That is genuinely valuable, and the case for running it continuously is a strong one.

The difference is what happens next. The tool produces a list of candidates; the engagement is what turns candidates into findings. Where that line falls, and what each side is good at, is set out in what a scanner finds, and what it cannot.

Applying this to a report you have

Take the highest-severity finding in any report and check it against the six: is it confirmed or suspected, is the severity reasoned, does it name the mechanism, is the remediation specific, is impact stated, is it classified?

Six out of six is a written finding. Two out of six is a scanner alert with a cover page — and the useful thing about checking is that it takes about a minute.

Security Brigade publishes complete sample reports — web application, network, red team and secure code review — with the finding detail, vectors, roadmap and compliance mapping intact, which is a more useful comparison than any description of one. How to read what you find there is in how to read a security finding.