Most scanner results are not findings

A scanner gives you a list. Your client needs a short, true story about what is wrong and what to do first. The distance between the two is where most of the report-writing time goes, and most of it is avoidable.

Group before you read#

Scanners repeat themselves. One weakness on forty URLs is forty rows, and reading them one by one is how a Friday disappears. Group the results by kind of issue first. In the example scan we use for CipherProof, 231 raw results turn into 12 kinds. Now you are making 12 decisions, not 231.

Ask three questions about every kind#

• Is it real? Can you reproduce it by hand? If you cannot, it is a lead, not a finding.
• Does it matter here? A missing header on a host that serves only static images is not the same problem as a missing header on a login page.
• Can the client act on it? If the fix is unclear, the finding is not finished yet.

Know the usual false positives#

• Version-based vulnerabilities. The banner says an old version, but the vendor has back-ported the fix.
• "Possible" injection. A parameter that reflects a payload is not the same as one that executes it.
• Informational noise on out-of-scope hosts. Valid observations, wrong report.
• Duplicates under different names. Two plugins describing one weakness.

Re-rate, do not copy#

A scanner's severity is generic. Yours should describe this client's environment. Work through the CVSS 3.1 vector yourself: how the attacker reaches the target, what privileges they need, whether a user has to click, and what is lost. Two people will not always agree on every metric, which is why the vector is printed next to the score. It lets the client see how you got there.

Write for the person fixing it#

• Impact in one sentence. What can an attacker do, in plain words.
• Steps to reproduce. Short enough that a developer can follow them without calling you.
• A specific fix. "Use parameterised queries in the order search" beats "sanitise input".
• Screenshots with the secrets covered. Hide tokens, cookies and other people's personal data before the image goes into a report.

Remember your decisions#

You will meet the same false positive on the next project. Write the decision down once. In CipherProof you can mark a kind of result as a false positive "always", and the Inbox will already have it set aside next time. Whatever tool you use, the habit matters more than the tool: triage should get faster with every engagement, not start from zero.