Guides · ← All guides
Reading Your Scan Results: Which Findings Fix First?
Last updated: October 31, 2026 · Reviewed October 2026 · 7 min read
A first scan report is a confronting document: a number, a list, and the sinking feeling that all of it is on fire. It is not. Reports are sorted problems, and the sorting logic is knowable — because the score is not a mood, it is arithmetic. This page explains how BreachHunter's scoring works, using the engine's real deduction values, so you can triage any report (ours included) with confidence. If your report is from a human pentest instead, start with reading your first pentest report; the two documents reward different reading orders.
How is the score calculated?
Every scan starts at 100. Each finding deducts points set by the finding's severity and exploitability, defined per check in the engine:
| Finding (real engine checks) | Severity | Deduction |
|---|---|---|
| Telnet exposed | CRITICAL | −15 |
| RDP / Redis / MongoDB exposed | CRITICAL | −12 each |
| Exposed .env file · .git directory · .git/config · AWS credentials · SSH private key · .env backups | CRITICAL | −10 each |
| MySQL exposed | HIGH | −10 |
| phpinfo page · config.php · backup archives · SQL dumps · phpMyAdmin · .svn metadata · git logs | HIGH | −8 each |
| Admin panel / WordPress admin reachable | MEDIUM | −5 |
| .DS_Store · server-status · package.json · composer.json | MEDIUM | −4 |
| Missing CSP / X-Frame-Options / X-Content-Type-Options | MEDIUM | −3 each |
| Missing HSTS | MEDIUM | −4 |
| Missing Referrer-Policy / Permissions-Policy · readable .htaccess · exposed Dockerfile | LOW | −2 each |
Source: SENSITIVE_PATHS, RISKY_PORTS and SECURITY_HEADERS tables, BreachHunter engine (app/pentest.py), read October 31, 2026. Read the table as an effort ranking: the deductions are highest where an attacker's path from found it to owns something is shortest.
What counts as "fix it today"?
The CRITICAL band, and within it, secrets first. An exposed .env, private key or .git directory is not a vulnerability waiting to be exploited — it is a download that may already have happened, which is why the fix has two halves: close the exposure and rotate everything it contained. Closing without rotating is locking a door after handing out copies of the key. (The full mechanics: what an exposed .git leaks.) Open Telnet, RDP, Redis and MongoDB ports are the same-day remainder: each is a direct, well-tooled path into the machine or the data.
Which highs should you verify before fixing?
HIGH is where judgement earns its keep. Some highs are unconditional — a public SQL dump is a public SQL dump. Others describe a surface that may be a deliberate, defended choice: phpMyAdmin reachable from your office IP only is a different fact from phpMyAdmin reachable from everywhere, and a scan from outside sees the second one. The rule: before you downgrade any finding as "intended", test the intention from outside your own network. Controls that exist on paper but not on the wire are how exposures survive audits. Mark verified-intentional findings as accepted risk, in writing, with a review date — not as closed.
What can safely wait for the weekly pass?
The MEDIUM and LOW bands: missing headers (real protection, configuration-sized effort — each header mapped to its attack), metadata files like package.json that aid an attacker's research but open nothing themselves, and hygiene items. They matter in aggregate — a report full of mediums tells an attacker the house is unattended — but none of them outranks a single open critical. Work them in a batch, in deduction order, after the top bands are closed. The small-team checklist turns most of them into a standing self-test.
How do you prove a fix worked?
Re-scan. A finding is fixed when the same check, run the same way from outside, no longer finds it — not when the ticket says done. BreachHunter Pro formalises this as Prove-It-Fixed: the check re-runs and the finding closes only when the exposure is gone, and drift tracking re-opens it if the exposure returns in a later deploy. Keep the before/after pair; together they are your evidence trail for customers, insurers and auditors who ask how you handle findings. Then run the whole cycle again next deployment — the report is a snapshot, and the scan itself is cheap enough to be a habit.
Get your own fix-first list — free scan →
Frequently asked questions
My score is low but I have no critical findings. Should I panic?
No. A pile of mediums — missing headers, an exposed admin login, metadata files — drags a score down without any single one being an emergency. Work them in order this week. The score is a triage instrument, not a verdict: what matters is whether anything rated CRITICAL is open, and how fast the total is climbing back.
Can a scan finding be a false positive?
Yes, and the honest response is to verify, not to dismiss. A phpMyAdmin finding may be a panel you deliberately expose behind IP rules and MFA — that is a managed risk, not a hole. But verify the control actually works from outside your network before you downgrade the finding; 'we meant to restrict that' is how exposures survive audits.
How do I prove a finding is fixed?
Re-scan the same target and compare. BreachHunter Pro's Prove-It-Fixed flow re-runs the check and closes the finding only when the exposure is actually gone, and drift tracking flags it if the exposure ever comes back.
In what order do professionals actually fix scan findings?
Secrets and source exposure first (same day, with rotation), then internet-facing database and remote-access ports, then high-severity application exposures, then the header and configuration mediums, then low-severity hygiene. Within a severity band, fix the item whose exploitation needs the least attacker effort first.