CySA+ Vulnerability Prioritization and Mitigation: CVSS, EPSS, Context and Remediation

You fix first the vulnerability whose likelihood of exploitation and business impact are together the highest, not simply the one with the highest severity score. A CVSS base score describes how bad a flaw is in general; prioritization adds what only your organization knows: whether attackers are using it, whether they can reach the system, what the system is worth and whether a fix exists.

CySA+ objective 2.3 lists the criteria an analyst weighs:

A useful order of reasoning: first confirm the finding is real, then ask whether it is being exploited and whether attackers can reach it, then weigh asset value and impact, and finally choose the mitigation that fits what the vendor offers. When several findings tie on one criterion, the next criterion decides. When a scenario states that some criteria are equal, the answer turns on the one that is not.

Exploitability measures how easily an attacker can use a flaw; active exploitation is proof that attackers already are. Both raise priority, and among the systems attackers can actually reach, confirmed exploitation outranks a prediction or a severity estimate, because the risk is no longer theoretical.

Exploitability factors

• Attack vector: network-reachable flaws are easier to reach than adjacent-network, local or physical ones.
• Attack complexity and requirements: a flaw that works every time beats one that depends on conditions outside the attacker's control.
• Privileges required: read this against how accounts are actually issued. Where accounts are self-service, as on a public forum, a free-trial sign-up or a consumer loyalty app, "low privileges" is barely a barrier; where accounts go only to vetted employees on a managed network, the same metric genuinely limits who can attack.
• User interaction: if the flaw needs a person to open a file or follow a link, ask whether anyone ever does that on the affected system. An unattended appliance or a service host that no one uses interactively is a weaker target than the advisory's generic score suggests, while the same component on a busy workstation is not.
• Exploit availability: public proof-of-concept code, and especially a weaponized module in a framework such as Metasploit, lowers the skill needed. Attackers take the easiest path, not the highest score, so when severity and ease of exploitation point different ways, weigh reachability, prerequisites and ready tooling rather than the number alone.

Active exploitation and the CISA KEV catalog

The Known Exploited Vulnerabilities (KEV) catalog, maintained by the US Cybersecurity and Infrastructure Security Agency (CISA), lists CVEs with reliable evidence of exploitation in the wild and clear remediation guidance. US federal civilian agencies must remediate KEV entries by set deadlines under Binding Operational Directive 22-01; most other organizations use KEV as a "patch these first" list. A vendor advisory stating that a flaw is under active attack carries the same weight.

The ranking that follows from this: known exploitation > public exploit code > no known exploit, applied within the systems attackers can actually reach. A KEV listing can therefore lift a moderate base score above higher-scored flaws that nobody is exploiting. Proof-of-concept code shows a flaw can be exploited; it is not evidence that anyone is doing so.

Asset value and impact decide how much damage a successful exploit would do, so identical findings on different systems get different priorities. Asset value is what the system and its data are worth to the business; impact is which security property (confidentiality, integrity or availability) the flaw harms and whether that property matters for this particular system.

Asset value is about the data and function, not the label

Rank by what the host actually holds and does, not by its environment tag. A non-production system loaded with real records (a training environment restored from a production backup, say) is as valuable to an attacker as the original, and usually less protected; a system tagged "production" that only publishes information already public may be worth little. Regulated and sensitive data, such as personal identifiers, health records, cardholder data and financial records, outranks systems that hold nothing an attacker could use.

Impact is read against the system's purpose

• Availability dominates for life-safety and real-time systems such as emergency dispatch, industrial safety controllers or a trading engine, where an outage is the harm.
• Integrity dominates where other systems trust what this one produces: a code-signing service, a package mirror, a configuration-management server or internal DNS. Tampering there spreads to everything downstream even though nothing secret is stored.
• Confidentiality dominates where regulated or sensitive data lives.

Read each CVSS impact value against the system's function. High ratings on a system that holds nothing and connects to nothing describe little practical harm, while a single high rating on the property a critical system depends on can be decisive. "No confidential data here" is never on its own a reason to rate impact low, because integrity or availability may be what matters.

Context awareness means scoring a finding by who can actually reach it: external (internet-facing) systems come first, internal systems next, and isolated systems last, once the isolation has been verified.

Three rules keep context honest:

• Context changes priority, not truth. A real flaw on an isolated host is still a true positive. It moves down the queue but stays recorded, scanned and scheduled like any other finding.
• Isolation is a claim to test. It must be demonstrated by routing, firewall and transfer controls, not assumed from a diagram.
• Exposure can outweigh score. A KEV listing proves exploitation somewhere, not reachability here. A remotely reachable flaw under attack outranks a higher-scored one on a system no attacker can reach remotely, whether or not the unreachable one is also listed.

You read a CVSS score by its vector, not its number: the base metrics describe the flaw itself, and the threat (temporal in v3.1) and environmental metrics tailor it to today's threat and your environment.

How do you read a CVSS base vector?

A CVSS base vector is a compact string of metric:value pairs that describes the intrinsic characteristics of a vulnerability; reading it lets you answer who can exploit the flaw, from where, and what it harms, without trusting the headline score. The base score is calculated from these metrics and is the same for every organization.

CVSS v3.1 base metrics

So "an unauthenticated attacker on the internet with no help from a user" is AV:N + PR:N + UI:N, whatever the AC or impact values say. Qualitative bands for scores are None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9) and Critical (9.0–10.0).

What changed in CVSS v4.0

• Attack Requirements (AT) is a new base metric: N (None) or P (Present). It records deployment or execution conditions of the vulnerable system that the attacker must overcome, such as winning a race condition or getting into an on-path (man-in-the-middle) position to inject traffic. Base metrics are scored assuming the configuration in which the flaw exists, so needing a particular configuration is not itself an attack requirement.
• Attack Complexity (AC) is narrowed to actions needed to evade or defeat security-enhancing techniques (for example, bypassing ASLR or DEP) or to obtain target-specific secrets such as a key.
• User Interaction becomes N (None), P (Passive: limited, involuntary interaction, such as rendering a modified web page or running an application that loads a planted file) or A (Active, such as importing a file or clicking through a warning).
• Scope is removed. Impact is split into the vulnerable system (VC/VI/VA) and subsequent systems (SC/SI/SA), which makes downstream harm explicit.

The AC/AT split matters because v3.1 put every hard-to-meet condition into Attack Complexity:

How do CVSS threat, temporal and environmental metrics tailor a score?

The base score describes the flaw; the other metric groups adjust it to the current threat and to your environment without changing the base metrics. If you disagree with how a vendor's flaw affects you, you record that in the environmental group, not by editing the vendor's base values.

Applying them

• Security requirements weight impact. CR, IR and AR say how much each property matters for this asset. A public status page that holds nothing secret but must never show false information would get CR Low and IR High, for example. The vendor's base values stay as published; only the requirement metrics change.
• Threat intelligence updates the threat metric. In v4.0, Exploit Maturity is Unreported (no known exploit code or attacks), POC (public proof-of-concept, no reported attacks) or Attacked (attacks reported or exploit tooling readily available). It is the only threat metric, so intelligence changes go there.
• Name the score you report. CVSS v4.0 labels its combinations CVSS-B (base only), CVSS-BT (base + threat), CVSS-BE (base + environmental) and CVSS-BTE (all three). A base-only score is a starting point, not a priority.

The Exploit Prediction Scoring System (EPSS), run by FIRST (the Forum of Incident Response and Security Teams), is a data-driven estimate of the probability that a CVE will see exploitation activity in the wild in the next 30 days. The CS0-004 objectives write it as "First Exploitability Prediction Scoring System"; it is the same FIRST model.

• Two numbers: a probability from 0 to 1 (0.61 means roughly a 61% chance of observed exploitation activity in the next 30 days) and a percentile showing how that probability ranks against all other scored CVEs. A low probability can still sit at a high percentile, because most CVEs have very low probabilities.
• Updated daily for published CVEs, so it suits ranking large backlogs.

Severity, likelihood and business impact are separate questions, and business impact comes from your own asset inventory and data classification, not from any of these three. EPSS is a model: it learns from historical exploitation data and public signals about each CVE, so it can lag fresh intelligence, and a CVE just confirmed as exploited may still carry a modest EPSS score for a while. That is why, when the sources disagree, observed exploitation outranks a prediction, and a strong prediction of exploitation usually outranks severity alone.

A finding is classified by comparing what the scanner reported with what is actually true on the host:

False positives: prove, record, suppress narrowly

False positives waste remediation effort and erode trust in the scanner. A classic cause is backporting: enterprise Linux distributions such as Red Hat Enterprise Linux apply security fixes to the version they ship and keep the upstream version number, so a banner-based (non-credentialed) check sees an "old" version and reports a CVE that the package changelog shows as resolved. Verify with the package manager or a credentialed check. Application scanners infer some flaws from side effects such as response delays or error text, and those side effects can have innocent causes, so reproduce an application finding by hand and review the code before deciding.

A confirmed false positive needs no risk acceptance, because there is no risk. Store the evidence with the disposition and scope any suppression to the exact asset and check involved, so the check keeps working everywhere else.

False negatives: the dangerous silence

A false negative is a real vulnerability the scan missed, and it is discovered only by other evidence such as an incident, an EDR or software inventory, or a penetration test. Common causes:

• Scan configuration: a non-credentialed network scan sees open ports and banners only. Client software that listens on no port, such as a PDF reader, office suite or mail client, is invisible to it, so a clean result says nothing about that software. Fix with credentials or agents.
• Coverage gaps: the host or application was never in scope.
• Detection lag: a scanner cannot report a CVE it has no check for, however often it runs. Until the check ships, exposure comes from matching the software inventory against the advisory's affected versions.
• Detection failure: even with a current check that ran against the host, a scan can still miss a vulnerable version; that is a false negative too.

A true negative is a correct "nothing found": for example, a credentialed scan with a current check on a host that is genuinely patched.

Mitigation means removing a vulnerability or reducing its risk; the objective names five strategies, and the right one depends on whether a fix exists, whether you can apply it now, and what stops the problem coming back.

Attack surface management

Attack surface management (ASM) continuously discovers internet-facing assets (subdomains, IP ranges, cloud services, certificates) and reduces the services they expose. Every other vulnerability process assumes the asset is already known; ASM is the one that finds shadow IT and forgotten systems missing from the CMDB, which were therefore never scanned. Reducing exposure means removing a service from the internet and putting access behind an authenticated gateway, such as an MFA-protected VPN or a zero-trust access broker. Changing a service's port is obscurity, not removal; hardening the service's own login leaves it reachable; and source-address allowlists hold only when the sources are stable.

Secure coding best practices

Application findings are fixed at the root cause in code:

• SQL injection: use parameterized queries (prepared statements with bound parameters) so input is always data, never SQL. Stored procedures are safe only when they use their parameters as data; one that builds a dynamic SQL string from them and executes it (EXEC) is as injectable as the original code. Input filtering, escaping and length limits are defence in depth, not the fix.
• Cross-site scripting: encode output for the context it is written into (HTML body, attribute, JavaScript, URL). Encoding neutralises any input, including text that legitimately contains special characters. Input validation is a supporting layer: blocklists of dangerous strings are bypassed with alternative encodings and tags, anything enforced in the browser is under the attacker's control, and strict allowlists cannot be applied to fields that must accept arbitrary text.

Patching and configuration management

Patch and configure at the source so findings do not recur: fix the golden image or base image and enforce settings centrally (Group Policy, configuration management, infrastructure as code) instead of hand-fixing each server. Container images are immutable build artefacts: a change made inside a running container is lost when the container is replaced. Fix the image's source instead, updating the base image (and any digest pin that would keep pulling the old one), then rebuild and redeploy. Urgent fixes use the emergency change process, which keeps change management's safeguards (expedited approval, a rollback plan, a post-change review) while removing the wait for a scheduled window.

When a finding cannot be remediated in time, the remaining two strategies, exceptions and compensating controls, apply; they are covered in the next section.

When a vulnerability cannot be fixed right away, apply any vendor workaround now, reduce the remaining risk with compensating controls, and record a formal, time-bound exception only for the risk that is left.

What do you do when no patch is available?

When no patch exists yet, apply the vendor's documented workaround or mitigation now (disabling the vulnerable feature, blocking untrusted input), add compensating controls if needed, and schedule the permanent fix. Waiting quietly for the patch leaves a known exposure open, and an exception is not the answer while a usable mitigation exists.

• Fix coming soon: apply the interim workaround (disabling a feature you do not use costs nothing), monitor, then patch and validate when the release ships.
• Fix only in a major version that needs long testing: combine an immediate mitigation (for example, a configuration that blocks the exploit technique) with an upgrade scheduled after proper testing, so both the risk and the business constraints are respected.
• Product or release out of support: no patch will ever come, so the permanent remediation is upgrading to a supported release (or replacing the product). Temporary controls and exceptions only buy time.

The CVSS v3.1 Remediation Level metric records this state (Official Fix, Temporary Fix, Workaround, Unavailable), but changing a score does not reduce risk; acting on the mitigation does.

When should you use an exception or a compensating control?

Use an exception when the organization must knowingly leave a real vulnerability unremediated for a while, and a compensating control to reduce that risk while it remains. An exception is a governance record; a compensating control is a technical or procedural safeguard.

What a defensible exception contains

• The finding, affected assets and the business reason it cannot be fixed (for example, a validated medical or manufacturing system that would need revalidation after any change).
• Approval by the accountable risk owner: someone with authority to accept business risk.
• The compensating controls in place.
• An expiry or review date. Exceptions are time-bound; a "permanent" acceptance of a fixable problem is not an exception.

Monitoring does not stop during an exception: the asset remains inventoried and scanned, so the record stays accurate and the review can see whether anything changed. An exception is the wrong tool when a fix or vendor workaround can be applied now, and repeated renewals are no substitute for upgrading software that will never be patched.

Choosing a compensating control

A compensating control must block the actual attack path and fit the stated constraints:

Where the host itself may not be changed, the control has to live off the host, on network devices: segmentation and ACLs that allow only the peers and protocols the system genuinely needs. Controls at the perimeter protect nothing from threats already inside the network.

A vulnerability is remediated when independent evidence shows the fix is in effect, not when a ticket is closed. Validation repeats the original test under the same conditions and checks that the fix is actually running.

• Rescan with the same scope, credentials and policy. A finding that only an authenticated scan could reach can only be cleared by a scan that authenticates to the same place; a lighter scan that never reaches the code proves nothing.
• Retest the original exploit or payload against the fixed input or service.
• Check the running version, not just the installed package. A new kernel package is not in effect until the host reboots: uname -r shows the running kernel, while rpm -q kernel lists the installed ones, and only the running one counts. Services and libraries loaded in memory behave the same way until restarted.
• Do not accept indirect evidence. Records of intent (an approved change, merged code, a closed ticket) do not show the fix is deployed, and a quiet period without attacks shows nothing about the flaw.

If the rescan still reports the finding, investigate before suppressing it: an unrebooted host, a configuration that reverted, an image that redeployed the old package, or a second copy of the vulnerable component are all common causes. Close the ticket only when the evidence clears it, and keep the finding visible if it cannot.