What Separates a Written Finding From a Scanner Alert

To tell what you paid for, take a single finding and ask what it would have looked like if a tool had produced it.

Below is an access-control finding from a published sample report, alongside the way automated tooling usually reports the same issue.

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.

It points at the right endpoint and names the right category. A developer receiving it still does not know whether it is real, what happens if it is, or what specifically to change.

Look at the words possible, may and verify. The tool has matched a pattern and handed 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.

The finding carries 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 after that depends on it: 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. Any authenticated user could read any other user's data. That is a critical outcome.

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 leaves 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. Somebody can make that code change this afternoon.

5. Impact spelled out

The written finding says what an attacker reaches: the profile data of any other user, by enumeration. That tells you how urgent the fix is, 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 that links it to published guidance. Several findings sharing a class expose the pattern behind them.

Where the scanner earns its place

The scanner was right 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. Run it continuously.

The difference is what happens next. The tool produces a list of candidates; the engagement turns them into findings. Where that line falls, and what each side is good at, are 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. The check 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. How to read one is covered in how to read a security finding.