Tutorial · HS Blog

How to read your first scanner finding without panicking

2026-05-06 · 6 min read

HorizonShield blog research workspace with threat notes and engineering analysis
Published article body and metadata remain served from the live CMS.
#scanner#vulnerability#triage#beginner

A finding lands in your inbox titled "Critical: SQL Injection — production-api-1." Your stomach drops. This guide walks you through the next ten minutes — what to read first, what to ignore for now, and how to know whether the alarm is real.

A finding lands in your inbox titled "Critical: SQL Injection — production-api-1." Your stomach drops. The instinct is to either panic-page everyone or close the tab and hope it goes away. Both are wrong. This is what to do instead.

Step 1 — Read the title and the severity, then stop

Every scanner finding has a category, a target, and a severity. Read those three things before you read anything else. The category tells you what class of problem this might be. The target tells you which system to think about. The severity tells you whether to keep reading right now or schedule a slot for it tomorrow.

If the severity is critical or high on a production-facing system, keep reading now. Otherwise, put it on the queue and move on. This sounds obvious — most people do not actually do it.

Step 2 — Confirm the finding is real

A scanner has a confidence score on every finding. Even high-confidence findings have false positives. Before you escalate, do one of these three things:

  • Reproduce the finding manually, with care
  • Pull the raw evidence the scanner attached
  • Ask the scanner what it actually checked

If the scanner says "this endpoint accepts a SQL string and returns a database error," look at the request and response yourself. Sometimes the "error" is the application's normal validation message and the scanner misread it. Sometimes the endpoint really does pipe input straight into a query. The difference matters.

Step 3 — Place the finding on a map

Three questions:

  1. Is this system reachable from the public internet?
  2. Does it touch sensitive data?
  3. What permissions does an attacker who exploits this gain?

A SQL injection on an internal admin tool with read-only credentials is not the same animal as a SQL injection on a public API with write permissions to the customer database. The CVSS score might be identical. The risk is wildly different.

Step 4 — Decide on the right response shape

There are three response shapes, in increasing intensity:

  • Schedule a fix. Routine work, normal sprint cadence. Most low and medium findings.
  • Fix this week. Higher severity or higher exposure, but not actively under attack.
  • Stop everything. Active exploitation, pre-disclosure embargo expiring, or a finding so severe that any delay is unacceptable.

The trap is treating every critical as "stop everything." If you do that for the third critical that turns out to be a false positive, the team will not stop everything for the fourth one — and that one will be real.

Step 5 — Communicate up before you have all the answers

If you confirm the finding is real and high-impact, tell your manager and the affected service owner before you have a complete fix plan. Two-line message:

> "We have a confirmed SQL injection on production-api-1. I'm investigating impact now and will have a status update in an hour. Loop in legal if you want to."

Bad news travels fastest when it travels first. People resent being told late, not being told early.

What to skip on the first read

  • The vendor's marketing language about why this finding is uniquely catastrophic
  • The CVSS sub-score breakdown (it almost never changes the response shape)
  • Forum threads from 2017 about whether this scanner has false positives in general
  • Any urge to write a long incident report before you have facts

A practical checklist for the first ten minutes

  • Read title, severity, target — 30 seconds
  • Pull the raw evidence — 2 minutes
  • Reproduce or rule out — 5 minutes
  • Map exposure (internet, data, permissions) — 1 minute
  • Decide response shape — 1 minute
  • Send the first communication — 30 seconds

If the finding is real and high-impact, the rest of your day belongs to it. If it is a false positive, you have given it ten minutes of attention, documented the dismissal, and moved on. Either way, you have not panicked.

The skill that develops over time

Scanner findings are easier to read on the hundredth one than on the first. The pattern of "category + target + severity → confirm → map → decide" becomes muscle memory. The first one feels like an emergency. The hundredth one is just a Tuesday.

The goal of this guide is to get you to the second one without it being an emergency either.

← All posts