How to read a website security report — without panic | Scanthra

Scanthra · 7 min read · Updated May 2026

Why these reports feel scary at first

Most security reports were written, originally, by penetration testers for other penetration testers. They use words like "vector", "vulnerable subdomain takeover", "missing HSTS preload" as if everyone reads them over coffee. If you're the owner of a small website and you just opened a PDF full of red boxes, the natural reaction is panic, followed by closing the tab.

Don't. Almost every modern report — Scanthra's included — is structured the same way underneath the styling, and once you know where to look, you can read one in about ten minutes.

The four things every finding tells you

1. Severity — how bad is it, in theory?

Severity is the worst-case impact if the issue is real and someone exploits it. It almost always uses five levels:

• CRITICAL — direct, immediate harm. Examples: a publicly readable .env file with database passwords; a subdomain that an attacker can take over and host phishing on. Treat as fix today.
• HIGH — serious but not instant. Examples: an old WordPress version with known exploits; missing TLS on the main domain. Fix this week.
• MEDIUM — would help an attacker who already has a foothold. Examples: missing security headers, weak cookie flags. Fix this month.
• LOW — hygiene. Examples: server banner reveals software version. Fix when you're next in there anyway.
• INFO / Observation — not a problem, just a thing we noticed (e.g. "you use Cloudflare"). Useful context, no action.

2. Confidence — how sure are we?

Passive scanners look at your site from the outside, the way a visitor would. They can't always be 100% sure a finding is real. Confidence is a number, usually 0–100%, that tells you how confident the tool is in the detection itself — separately from how bad the issue would be.

Scanthra uses a 2D model: each finding has both a severity and a confidence. We only show findings with confidence ≥ 50%. Anything below that lives in the Observations section, where we say "we noticed this, we're not sure, here's why" instead of crying wolf.

A practical reading order:

1. HIGH or CRITICAL severity at ≥ 80% confidence — start here.
2. MEDIUM severity at ≥ 80% confidence — schedule into a sprint.
3. HIGH or CRITICAL at 50–80% confidence — verify first, then fix.
4. Everything else — batch into a maintenance window.

3. The fix — one paragraph, in English

Every finding worth its salt comes with a short "how to fix" paragraph that a developer can act on. In Scanthra reports this lives under Fix it yourself: usually one or two sentences, sometimes a copy-pasteable config snippet. If you don't run the site yourself, this is the part you forward to whoever does — your web developer, agency, or hosting support.

You don't have to understand the fix. You just have to be able to hand it off and ask "can you do this, and when?".

4. Compliance tags — who cares about this besides you?

Findings often carry tags like GDPR:Art32, NIS2:Art21, OWASP:A05. These are shortcuts that say "this isn't just our opinion; regulator/standard X expects you to handle this". The three you'll see most:

• GDPR Art. 32 — the EU's general "appropriate technical and organisational measures" clause. Things like encryption in transit (HTTPS) and breach-resilient configuration land here.
• NIS2 Art. 21 — the EU NIS2 Directive's baseline measures: risk management, vulnerability handling, supply-chain security, encryption, access control. Even if you're not a regulated entity yourself, large customers will increasingly ask you about these.
• OWASP Top 10 — the industry-standard list of the most common web application risks. A05 is misconfiguration, A07 is identification and authentication failures, and so on.

What about false positives?

No passive scanner is perfect. Sometimes a tool will flag something that, in the specifics of your setup, isn't actually a problem. Examples:

• A "missing security header" that's actually set by your CDN further upstream and the scanner couldn't see.
• A "CMS version is outdated" warning where the version string is deliberately spoofed by a hardening plugin.
• A "subdomain points nowhere" where the subdomain is intentionally parked for an upcoming launch.

When in doubt: fix anyway. Almost every "false positive" is cheap to neutralise, and doing so removes the noise from your next scan too. The exceptions are cases where the fix would cost real work — there, ask your developer to confirm before you spend hours.

How to share a report with a developer

If you're forwarding the PDF, three sentences are enough:

"Hi — we ran a security scan. Could you look at the HIGH and CRITICAL findings starting on page 4 and let me know which ones you can fix this sprint and which need more scoping? I'm happy to deprioritise anything LOW for now."

That's it. The developer doesn't need a translation of the report; they need permission to prioritise.

What a "clean" report looks like

Spoiler: nobody gets zero findings on first scan. A typical small-business WordPress site lands on ~8–15 findings, mostly MEDIUM headers and cookie hygiene. A reasonable target for "clean" is:

• Zero CRITICAL.
• Zero HIGH older than 30 days.
• An overall grade of B or better on the cover page.

Anything beyond that is gold-plating — useful, but not the gap between you and your customers.

How Scanthra writes its reports

We deliberately keep the language plain. Every finding has a business impact line ("if exploited, an attacker could read customer emails, which would be a GDPR breach"), a fix-it-yourself paragraph, and a compliance map at the start so you can see at a glance which regulators care. If a finding is borderline, we move it to Observations rather than scaring you. The goal is a report you can read on the train home and act on the next morning — not a 60-page PDF you file under "scary, deal with later".