How to Read a Security Scan Report: Severity, False Positives and What to Fix First

Read a scan report as a prioritised list of hypotheses, not a verdict. Each finding has a severity, which estimates worst-case impact, evidence, which is what the scanner actually observed, and a fix. Confirm the evidence yourself, discard what does not apply, then work in order of exposure: leaked secrets first, broken transport second, exploitable versions third, session protection fourth, and headers and informational items last.

The anatomy of a finding

Every serious scanner reports the same four things per finding, however it lays them out. A check identifies what was tested, for example Cookie without HttpOnly flag. A severity ranks it. The evidence is what the scanner saw: the exact header, the response to a specific URL, the version string in a script path. The remediation says what to change. Of the four, the evidence is the one to read first and the one most people skip. A finding whose evidence you cannot reproduce is not a finding; it is a hypothesis the scanner could not rule out, and every scanner has some of those.

Scan.now reports link each finding to its knowledge-base page, which explains what was tested, why it matters and how to fix it, so the report itself stays short. The grade at the top, A through F, summarises the findings weighted by severity; it is a convenient number for tracking and a poor one for deciding what to do, because two sites with the same grade can have entirely different problems.

Where severities come from

There are two distinct sources of a severity label, and reports rarely say which one applies. For a known vulnerability in a named product, the severity usually derives from a CVSS score: a computed number from a published vector, explained in CVE and CVSS Explained. For a configuration state, such as a missing header or a cookie flag, there is no CVSS score, and the severity is the scanner's judgement of how much that state usually matters. Scan.now uses the CVSS qualitative scale for both, which keeps one vocabulary but means "high" can mean "computed 8.1" or "we think this is usually serious".

Severity encodes impact, not likelihood and not effort. A critical finding that takes one line of nginx to fix and a low finding that takes a week of refactoring are both worth doing, but the order and the urgency are different, and the label alone does not tell you either.

Spotting false positives

A false positive is a finding whose evidence is real but whose conclusion is wrong. They cluster in predictable places, and knowing the clusters lets you clear most of them in minutes.

• Version-based detection with backported fixes. A header says Apache/2.4.52; a naive scanner lists every CVE fixed after 2.4.52. On Ubuntu or Debian the package at 2.4.52 has those fixes backported. Passive scanners that report a version as a disclosure rather than as a CVE list, which is what Scan.now does under Server version disclosure, avoid this class entirely; if you see a CVE list derived from a server header, check the distribution's changelog before believing it.
• The scanner hit a different page than you think. Redirects to a login, a CDN's error page, a maintenance page or a bot-challenge page all have their own headers and cookies. A "missing CSP" finding on a Cloudflare challenge page says nothing about your application. Check the evidence URL and status code.
• Headers set on some responses and not others. The application sets security headers; the static file server or the error handler does not. The finding is real for the path scanned and may be irrelevant or may be the more important gap. Look at which URL was tested.
• Deprecated advice reported as missing. A report that flags the absence of X-XSS-Protection is out of date; browsers removed the feature and Scan.now reports its presence, not its absence, under X-XSS-Protection (deprecated header). Treat any scanner that demands it as a warning about the scanner.
• Library fingerprints on bundled or forked code. A file that includes a jQuery copyright banner from a patched fork will be identified as the original version. Check the actual file and the changelog of the bundle.
• Cookies that are not yours. Analytics and consent cookies set by third-party scripts appear in your scan with their flags, which you cannot change. Note them and move on.

Confirming a finding in thirty seconds

Before you file a ticket, reproduce the evidence. For almost every finding in a passive web scan, one curl command is enough, and reading the raw response teaches you more than any report summary.

# headers and cookies on the page the scanner tested
curl -sI https://example.com/ | sed -n '1p;/^strict-transport\|^content-security\|^x-frame\|^set-cookie/Ip'

# is the exposed file really there?
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/.git/HEAD
curl -s https://example.com/.env | head -c 200

# which TLS versions does the server accept?
openssl s_client -connect example.com:443 -tls1_1 < /dev/null 2>&1 | grep -E 'Protocol|alert'

# what does the DNS actually say?
dig +short TXT _dmarc.example.com

If the reproduction matches the evidence, the finding is real. If it does not, note why: a CDN serving different headers per region, a fix already deployed, a scanner that followed a redirect you did not expect. Either way you now understand the finding well enough to explain it to whoever has to fix it, which is the actual purpose of reading the report.

A triage order that fixes the most exposure per hour

Sorting by severity is the obvious approach and it is nearly right. The adjustment is to sort by exposure removed per hour of work, which promotes cheap critical fixes to the top and pushes expensive medium ones down. In practice that produces this order for a typical passive scan:

1. Leaked secrets and source. Exposed .env, .git, backups and debug pages. Block the path now, rotate everything, then investigate. Minutes of work, breach-level exposure. See Exposed Files.
2. Broken transport. Invalid or expired certificates, no HTTPS redirect, TLS 1.0 or 1.1 accepted. These undermine every other control and are usually a configuration change.
3. Known-exploitable versions. Libraries and CMS components with published CVEs, prioritised by whether the flaw is reachable and exploited in the wild, not by score alone.
4. Session and content protection. Cookie flags, active mixed content, insecure form actions. Each is one line in a framework config or template.
5. Headers. HSTS, frame-ancestors, nosniff, Referrer-Policy, Permissions-Policy, then a CSP, which is the one item here that takes real effort. HTTP Security Headers Explained gives copy-ready values for each.
6. Disclosure and hygiene. Server versions, generator tags, directory listings, xmlrpc, user enumeration. Cheap, worthwhile, not urgent.
7. Informational items. Read them once for anything surprising, such as a third-party script you did not know was there, then ignore them.

Two findings deserve to jump the queue regardless of where they land: anything that appears in CISA's Known Exploited Vulnerabilities catalogue, and anything a colleague can confirm is being actively probed in your logs. Everything else can follow the order.

Reading the grade honestly

A letter grade compresses a report into a signal, which is useful for tracking and for explaining progress to someone who will not read the findings. It has three limits worth stating. It reflects only what the scanner tested, so a passive scan's A says nothing about the login form's resistance to injection. It is sensitive to what page was scanned; the home page and the checkout can differ. And it is not comparable across scanners, because each weights findings differently. Use the grade to answer "is this better than last month?", never "is this secure?" The website security hub explains each area the grade summarises.

After the fixes

Re-run the scan after each batch of changes rather than after all of them, so you can tell which change had which effect and catch a fix that broke something else, such as an HSTS header that did not survive a CDN configuration update. Keep the reports. The first report shows what was wrong; the second shows whether the deployment process now prevents it, which is the more important fact. A finding that reappears after being fixed is a process problem, and process problems are the ones a scanner is best at revealing, because it never gets tired of asking the same question.

Passive scanning is one of four kinds of scan; the pillar guide The Complete Guide to Security Scanning shows how browser, file and privacy checks fit around it, and the website security hub covers each area a website report will touch. When you are ready to read your own, the website scanner produces exactly the kind of report described here, with every finding linked to its explanation.

Our position: the report is where the work starts, not where it ends. A team that confirms each finding, fixes in exposure order and re-scans will get more security from a free passive scan than a team that forwards a PDF of two hundred unverified findings to a ticket queue and calls it done.