Prioritising and remediating what the scan found

Why this matters

A first scan of any real estate returns thousands of findings. The organisation cannot fix thousands of things, so the only question that matters is which ones first — and the default answer, sorting by severity score, is wrong in a specific and consequential way.

It is wrong because severity describes how bad a vulnerability would be if exploited, in the abstract. It says nothing about whether the affected thing is reachable, whether anyone is actually exploiting it, or whether the data behind it matters. A team working strictly down a severity list spends its effort on internal systems while an exposed, actively-exploited medium sits untouched.

This lesson is about turning a list into a work queue, and about closing findings honestly.

The lesson

CVSS as a starting point and not a work queue

The Common Vulnerability Scoring System gives a vulnerability a score from 0 to 10 and a rating from none to critical. It is standardised, widely published, and genuinely useful — as an input.

What it is built from is worth knowing, because it explains the limitation. The base score describes the vulnerability's intrinsic characteristics: how it is accessed, how complex exploitation is, what privileges are needed, whether a user must interact, and what the impact is on confidentiality, integrity and availability. That is a property of the flaw, identical for everyone in the world who has that software.

The scores almost nobody uses are the ones that make it relevant:

• Temporal metrics adjust for whether exploit code exists and whether a fix is available — so the score changes over time as the world changes.
• Environmental metrics adjust for your deployment: how exposed the asset is, and how much the confidentiality, integrity or availability of that particular system matters to you.

Most organisations consume the base score and ignore both. The result is a queue ordered by a number that was never meant to be a priority, and this is the precise reason a base-score work queue misallocates effort.

Treat CVSS as one input, and combine it with the factors below.

Exploitability and exposure: an internet-facing medium above an internal critical

The two factors that should outrank raw severity.

Exploitability — is it actually being used? A vulnerability with public exploit code, or one listed in a known-exploited catalogue, is categorically more urgent than a theoretical one with a higher score. Most published vulnerabilities are never exploited at scale; a small number are exploited within days. Feeds that track this are widely available and they change the ordering dramatically.

Exposure — can an attacker reach it? A critical vulnerability on a host with no inbound path, reachable only from a private subnet, behind authentication, is a much smaller problem than a medium on something internet-facing. This is where cloud context genuinely helps: the platform knows whether a security group permits inbound from the internet, whether a subnet has a route to a gateway, and whether a load balancer targets the host. Modern cloud security tooling correlates vulnerability with reachability automatically, and that correlation is the single biggest improvement available to a prioritisation process.

Then add the third factor, asset value: what the system holds and what it does. A vulnerability on a host processing cardholder data outranks the same vulnerability on a build agent.

So the practical ordering is roughly:

Exposed + exploited + valuable asset → now, as an emergency change. Exposed + exploitable → this cycle. High severity, not exposed → routine patch cycle. Low severity, not exposed, low value → accept or fix opportunistically.

An exam scenario handing you a critical on an internal host and a medium on an internet-facing one, with exploitation in the wild, is testing exactly this — and the medium wins.

Remediation, mitigation and accepted risk as three different recorded outcomes

Every finding ends in one of four outcomes, and using the words precisely is part of the skill.

• Remediate. Fix the vulnerability — patch, upgrade, reconfigure, replace. The finding is genuinely gone.
• Mitigate. Reduce the risk without removing the vulnerability: put it behind a firewall rule, disable the affected feature, add a compensating control such as a WAF rule or stricter network policy. The vulnerability remains and the exposure is reduced. Legitimate and common, particularly when no patch exists or the system cannot be changed — the hardware-bound workloads from objective 2.1.
• Transfer. Shift the consequence elsewhere, typically by contract or insurance. Rare for a specific vulnerability and worth knowing as one of the four standard risk responses.
• Accept. Decide the risk is tolerable and do nothing. Legitimate, and only when it is a recorded decision by someone with the authority to make it, with a stated reason and a review date.

What makes acceptance professional rather than negligent is that it is written down, owned by a named person, time-bounded, and reviewed. An unrecorded acceptance is indistinguishable from having forgotten, and the difference becomes very visible after an incident.

Track the accepted set as a register, review it on a schedule, and re-evaluate when circumstances change — because exposure and exploitability change even when the vulnerability does not. Something accepted last year because no exploit existed is a different decision once one does.

Patch, replace or rebuild, and why immutable infrastructure makes the third easiest

Three ways to remediate, and the cloud shifts which is easiest.

Patch in place. Update the package on the running system. Familiar, and it creates the drift problem from objective 2.2: the running system no longer matches the image it came from, so the next instance the scaling group creates is vulnerable again. Patching an autoscaling fleet in place is a temporary fix that silently reverts. That is one of the most useful things to know in this lesson.

Replace the instance. Build a new image with the patch, then roll instances (objective 3.1). The fix is in the image, so every future instance has it, and verification is simple: check the image version. This is the right answer for almost everything in an elastic estate.

Rebuild the environment. For a vulnerability in something foundational, or where the system may already be compromised, recreate from code. Infrastructure as code is what makes this practical, and where compromise is suspected it is the only trustworthy option — patching a possibly-compromised host leaves the attacker's persistence in place.

The order of preference in a cloud is therefore usually replace, then rebuild, with in-place patching reserved for stateful systems that cannot be replaced — databases, licensed appliances — where the snapshot-and-rollback plan from objective 3.1 applies.

Remember the fourth option the scanner never suggests: remove it. A vulnerability in a component nobody uses is best fixed by deleting the component, which is the decommissioning discipline from objective 3.1 doing security work.

Verifying the fix and closing the finding with evidence rather than assertion

A finding is not closed because someone says they fixed it. This is the same principle as restore testing: the claim is not the evidence.

Verify by rescanning, and make the rescan the thing that closes the finding — automatically, if the tooling allows. That removes the most common failure, which is a ticket closed in one system while the vulnerability persists in another.

What goes wrong between "patched" and "actually fixed":

• The patch was applied and the service never restarted, so the vulnerable code is still running from memory. Extremely common with shared libraries, and a rescan of the package version reports success while the process continues to use the old one — so verify the running state where it matters.
• Patched in one environment only. Production is fixed; staging, DR and the image are not, so the next deployment or failover reintroduces it.
• The image was not rebuilt, so the fleet regresses at the next scaling event.
• A dependency pinned elsewhere still pulls the vulnerable version.

Then measure the process, because these numbers are what tell you whether vulnerability management is working:

• Mean time to remediate, by severity and by exposure.
• Findings older than the policy allows, which is the backlog that matters.
• Recurrence — findings that were closed and came back, which almost always indicates an unrebuilt image or an unpatched template rather than a new problem.
• Coverage, from the previous lesson, because all of the above is meaningless without it.

Keep the evidence. Objective 4.4's auditor will ask for exactly this: the finding, the decision, the action, the date, and the rescan that confirmed it.

What to take into the exam

• CVSS base score is an input, not a work queue. The temporal and environmental metrics are the ones that make it relevant and the ones people ignore.
• Exposure and active exploitation outrank raw severity. An exposed, exploited medium beats an unreachable critical.
• Four outcomes: remediate, mitigate, transfer, accept — and acceptance is only legitimate when recorded, owned, time-bounded and reviewed.
• Patching an autoscaling fleet in place silently reverts at the next scaling event. Fix the image and replace.
• Where compromise is suspected, rebuild rather than patch.
• Close findings by rescan, not assertion. Watch for the patch applied without a service restart, and for one environment fixed out of four.