Vulnerability Scan Results: Turning a Scanner's Critical List into a Fix Queue

Q: How do you prioritize vulnerability scan results?

Sort by whether the vulnerable service is reachable from outside, whether the flaw is known to be exploited in the wild, and how much the affected system matters to the business, then use the scanner's severity score only to break ties. A medium-rated flaw on an internet-facing payment host usually outranks a critical-rated one on an isolated test box.

Q: Is CVSS enough to decide what to fix first?

No. CVSS describes how severe a flaw is in the abstract, not whether anyone is exploiting it, whether your instance is exposed, or what sits behind it. Treat it as one input next to exploitation evidence such as CISA's Known Exploited Vulnerabilities catalog and your own asset context.

Q: What is a false positive in a vulnerability scan?

A finding the scanner reports that is not actually present, often because it inferred a vulnerable version from a banner while the vendor had backported the fix. A related problem is the finding that is real but not reachable, which is true on paper and irrelevant in practice. Manual validation separates both from findings that matter.

Q: Should a scan be authenticated?

An authenticated scan logs in to the host and sees installed packages and configuration directly, so it finds far more than an anonymous one and produces fewer guesses. It needs credentials and a clear agreement on what the scanner may touch. Ask any provider whether the quote is authenticated, unauthenticated, or both.

Q: What should a vulnerability assessment report contain?

A de-duplicated list of validated findings grouped by affected asset, each with the evidence, a priority that explains why, a concrete fix, and a note of what was not scanned. A raw scanner export with a cover page is not an assessment.

The short answer

A vulnerability scanner returns a list sorted by its own severity score, and that list is not a work queue. To turn it into one, sort each finding by three questions: can an attacker reach it from where they sit, is it known to be exploited in the wild, and what does the affected system do for the business. Use the scanner's score to break ties, not to lead. Findings that fail validation, duplicates, and real-but-unreachable items come off the list first. What is left is the fix queue, and it is usually much shorter than the export.

Who this is for

This is for the security lead, platform owner, or compliance manager at a casino, crypto exchange, or fintech who has a scan export, or a first assessment report, and a team asking "where do we start?". It is about what happens after the scan. For what an external scan covers in the first place, see scoping an external vulnerability assessment for a casino; for how often to repeat it, see how often an online casino should run a vulnerability assessment.

Why the raw list misleads

Three things make a scanner export a poor to-do list:

It counts instances, not problems. One outdated library on forty hosts is forty rows. One fix, applied through a base image, removes all of them.
It cannot see context. The scanner does not know that one host takes card payments and another is a decommissioned demo box. Both get the same score for the same flaw.
It guesses. Many checks infer a vulnerability from a version string. If the vendor backported the fix without changing the version, the finding is false. Others are true but sit behind a control the scanner cannot see.

Teams that start at the top of the export spend their first week on the loudest items, not the riskiest ones.

Step 1: remove what is not a finding

Before ranking anything, clear three groups:

Duplicates. Group rows by root cause (the same package, the same misconfiguration, the same template) so a fix is one work item, not many.
False positives. Confirm the issue exists, by checking the actual package or configuration or by safely testing the behaviour. Record why it was dismissed so the next scan does not reopen it.
Informational noise. Banner disclosures and certificate notices are worth a line in the report, not a ticket.

This is the manual validation step. It is the main difference between an assessment and a scanner export, and it is the part to ask a provider about directly.

Step 2: rank what is left

For each remaining finding, answer in this order:

Question	Why it moves the priority
Is the service reachable from the internet, or only from inside?	Internet-facing flaws can be attacked by anyone; internal ones need a foothold first
Is the flaw known to be exploited?	Check CISA's Known Exploited Vulnerabilities catalog and vendor advisories. Exploitation in the wild outranks theoretical severity
Is there a public exploit or a trivial way to trigger it?	Easy to use means likely to be used
What does the asset do?	Payments, wallets, authentication, admin and customer data raise the stakes; a test host lowers them
Is a compensating control in place?	A WAF rule or network restriction can reduce urgency, but only if someone has confirmed it works
How hard is the fix?	A one-line config change goes in immediately even if its rank is middling

A workable output is three buckets: fix now, fix this cycle, and accept or schedule with a stated reason. The third bucket is legitimate, as long as each item has an owner and a review date.

Where the score still helps

CVSS is a sound description of how bad a flaw is if it is exploited, which is why it appears in assessment reports. Its limit is that it is context-free. Use it to order findings that are otherwise equal on exposure and asset value, and to talk to people outside security who need a common scale. Do not use it as the only sort key.

Authenticated or not changes the list

An unauthenticated scan sees what a stranger sees: open services, banners, responses. An authenticated scan logs in and reads installed packages and configuration directly, which finds more and guesses less. If the quote does not say which one it is, the number of findings is not comparable between providers. The same applies to internal versus external coverage, which is why scope belongs in the report as well as the quote.

What the assessment report should give you

Ask for these, and compare reports from different providers against them:

Findings grouped by root cause and affected asset, not one row per scanner hit.
Evidence per finding: what was observed and how it was confirmed.
A priority with the reason stated, using exposure, exploitation, and asset value.
A concrete fix, with the owner type (platform team, application team, vendor).
The false positives removed, listed briefly, so you can see the filtering happened.
A scope and limits statement: what was scanned, authenticated or not, and what was out of range.

If a finding needs more than a scan can answer, such as whether an exposed admin panel can be taken over, that is the point at which a penetration test is the right next step, as covered in vulnerability assessment vs penetration testing for iGaming.

Closing the loop

Fixing is half the job; confirming is the other half. A re-scan confirms that the signature is gone, which is enough for patch-level findings. For anything where the original issue was found by hand, ask for a retest, described in what counts as fixed after a pentest. Keep the triage decisions, including accepted risks, with the report: that record is what an auditor or payment partner will ask for.

Limitations

This is a triage method, not a service level. It sets no remediation deadlines for your organisation and does not interpret the patch-timing rules of a specific framework; check the current text of the one that applies to you. It cites no statistics and ranks no scanner or provider.

What to do next

Take your latest export, group it by root cause, and sort the survivors with the table above. If you would rather have the grouping and validation done for you, request a fixed quote for a vulnerability assessment and tell us whether you need external, internal, or both. The Vulnerability Assessment page describes how an engagement runs.

Frequently asked questions

How do you prioritize vulnerability scan results? By reachability, evidence of exploitation, and the value of the affected system, with the scanner's score used only to break ties.

Is CVSS enough to decide what to fix first? No. It does not capture exposure, exploitation, or what is behind the flaw. Use it next to those.

What is a false positive in a vulnerability scan? A reported finding that is not actually present, often a version guess where the fix was backported. Real-but-unreachable findings are a related source of noise.

Should a scan be authenticated? Authenticated scans find more and guess less, but need credentials and agreed boundaries. Ask what the quote assumes.

What should a vulnerability assessment report contain? Validated, de-duplicated findings by asset, with evidence, a reasoned priority, a fix, and a statement of what was not scanned.

Sources and review

This article describes triage practice in general terms. It refers to CISA's public Known Exploited Vulnerabilities catalog as a source of exploitation evidence and cites no statistics and no AnySec-original numbers, case results, or SLA figures. Author: AnySec Engineering. Published 2026-10-05; last reviewed 2026-10-05.