When Vulnerability Scores Disagree, What Should You Fix First?

I would first address an applicable vulnerability with credible exploitation evidence, a plausible path into a consequential service, and no verified protection that interrupts that path. A higher severity score on an unaffected product should not displace that work. Where applicability or protection is uncertain, the immediate action may be investigation or containment while a safe patch is prepared. Applicable mandatory deadlines remain constraints; a scoring preference cannot waive them.

That answer requires more than sorting a spreadsheet. CVSS describes technical severity, EPSS forecasts exploitation activity, and CISA's Known Exploited Vulnerabilities catalog records established exploitation. None independently identifies which deployment you operate, what its failure would interrupt, or whether a change can be made safely. This paper develops a decision method for resolving those differences without manufacturing a probability of organizational loss. The framework and worked examples are my analytical synthesis, not results from a client engagement or a patching experiment.

Establish what is actually disagreeing

Before reconciling scores, I would compare their definitions, versions, timestamps and affected products. Two analysts may be discussing different configurations or different stages of the same vulnerability's life. One dashboard may show a Base score while another incorporates threat information. A daily prediction and a month-old export do not describe the same evidence state. Apparent disagreement can therefore be a data-integration problem before it becomes a risk-management problem.

The CVSS v4.0 specification distinguishes Base, Threat, Environmental and Supplemental metrics. Base describes intrinsic characteristics; Threat incorporates changing exploitation information; Environmental reflects deployment-specific characteristics. Supplemental metrics provide context without modifying the resulting score. FIRST also requires published CVSS data to include the vector, making the underlying assessment inspectable (Forum of Incident Response and Security Teams [FIRST], 2024). I would retain that vector beside the score, its source and the relevant product version. A decimal stripped of those fields cannot explain why the vulnerability received its rating.

There can also be legitimate differences within CVSS. Its user guide permits multiple Base assessments when a vulnerability affects different versions, platforms or operating systems. It explicitly warns against treating Base severity alone as risk and recommends connecting scan findings to asset and threat information (FIRST, 2025). I would resolve a vendor/scanner discrepancy by comparing the claimed preconditions and effects. Choosing whichever number is smaller because it reduces the backlog is not reconciliation.

The first operational question is consequently narrow: are these records about the same vulnerability, the same deployed product and the same assessment context? Preserve conflicting assertions until that can be answered. When a supplier changes an advisory, the old decision should remain reproducible from the evidence available at the time, while the current queue uses the revised facts. Otherwise, a later review cannot distinguish a reasonable earlier decision from an unnoticed stale feed.

Probability, percentile and known exploitation are different evidence

EPSS estimates the probability that exploitation activity for a CVE will be observed in the wild over the next thirty days. FIRST publishes daily scores and distinguishes the probability from the percentile, which ranks it against other scored vulnerabilities. A high percentile is not the same number expressed as a percentage probability. The model does not include your deployment, compensating controls or business loss (FIRST, n.d.). I would store both values with the forecast date, but label them clearly enough that a change manager cannot mistake one for the other.

The research supporting EPSS is relevant because it explains what the forecast learns from. Jacobs et al. (2023) evaluate an evolving prediction model using observed exploitation and discuss the limitations of the contributing sensors. Their data do not capture every exploit attempt; coverage favors some attack environments, and signatures constrain what becomes visible. I therefore treat a low forecast as useful population-level evidence, not affirmative evidence that a targeted attack against a particular deployment is implausible. The study describes an earlier model generation, not a validation of every subsequent production version.

CISA applies different inclusion criteria to KEV: an assigned CVE identifier, reliable evidence of exploitation in the wild, and a clear remediation action (Cybersecurity and Infrastructure Security Agency [CISA], n.d.). A listing establishes a reason for urgent attention. It does not establish that your instance has been compromised. Conversely, absence from the catalog does not negate a credible supplier warning or local incident evidence. The catalog has an evidence and inclusion process; it is not an exhaustive sensor covering every organization.

When a listed vulnerability has a low current forecast, I would not average the signals. They answer different temporal questions. Prior observed exploitation remains relevant even if the prediction of activity in the next window is low. A high forecast without confirmed exploitation warrants preparation and prioritization, but does not become a declaration that an intrusion has occurred. This separation prevents both false reassurance and unnecessary incident claims.

Tie the CVE to the deployed artifact before assigning urgency

The unit I want to prioritize is a vulnerability instance in a particular deployment. A CVE can appear in an installed package, a container image, an appliance, a build dependency or several of these at once. The necessary evidence includes exact product identity, affected version range, configuration, deployment location and service owner. NIST's patch-management guidance connects vulnerability discovery to knowledge of the organization's assets and their software, including packages and libraries (Souppaya & Scarfone, 2022).

A component match begins this investigation; it does not finish it. I would ask whether the vulnerable code was included, whether the vulnerable function is used, and whether the relevant input can reach it. An installed-version query, a build record and a supplier advisory establish different things. If their identifiers cannot be joined reliably, keep the applicability unresolved and assign someone to resolve it. Counting an unmatched record as unaffected rewards weak inventory.

Vulnerability Exploitability eXchange, or VEX, can carry product-specific status and supporting explanations. The community-authored Minimum Requirements for Vulnerability Exploitability eXchange (VEX) (2023) distinguishes affected, not affected, fixed and under investigation, and associates statements with products, vulnerabilities, authors and update metadata. It is hosted by CISA but explicitly does not constitute official CISA policy. I would use such a statement as attributable evidence whose scope must match our artifact, not as a blanket permission to suppress a CVE everywhere.

The CSAF 2.0 standard likewise distinguishes product states including known affected, known not affected, fixed and under investigation. The last means the determination is incomplete, not that a product is safe (OASIS Open, 2022). An authentic supplier statement may still refer to a different release or an assumption the deployment violates. My acceptance test is therefore: can we identify the exact statement, match its product scope, explain its rationale, and detect the changes that would invalidate our reliance on it?

This is where an SBOM's role and limits matter. Component transparency helps find candidates. Applicability analysis determines which candidates belong in the remediation decision.

Replace the internet-facing checkbox with a credible path

Exposure is a relationship between an attacker, an interface and a vulnerable behavior. “Internal” is an administrative label until someone explains what prevents access. A service may be reachable through a partner connection, an authenticated application path or a compromised workstation. Equally, a publicly named service may not expose the vulnerable feature. I would document the relevant path and preconditions rather than treating a hostname or network zone as the whole analysis.

The original SSVC work emphasizes that exposure analysis requires asset information, network topology and knowledge of enforced controls; appearance in an external scanning database is not a complete answer (Spring et al., 2021). My practical adaptation is to write one short path statement: which actor can reach which interface, under which permissions, and what capability exploitation would provide. The statement should distinguish a direct route from an attack chain that requires an earlier compromise.

Consider a hypothetical internal deployment service with access to production signing credentials. Its network boundary may reduce some attack opportunities, but the consequence of compromising it can exceed the direct impact on that server. I would have the platform owner check the credential relationship, authorization boundary and downstream release process. That does not justify assigning it an invented critical score. It establishes a consequential scenario that the ordinary asset label may conceal.

Protection needs equally specific evidence. “Behind a firewall” leaves open which traffic is denied, whether alternate paths exist, and whether the control covers every affected instance. A vendor-supported feature disablement might interrupt the relevant behavior more directly than a broad monitoring claim. I would record what the control prevents, what it only detects, and which changes would reopen the path. No destructive exploit test is implied: configuration inspection, controlled connectivity checks and approved functional tests may provide the required evidence.

Use a decision policy that exposes its assumptions

SSVC offers a useful foundation because it produces response decisions from explicit conditions. CISA's 2022 guide uses exploitation, technical impact, automation, mission prevalence and public-well-being considerations, with four outcomes: Track, Track*, Attend and Act (CISA, 2022). These are different response expectations, not a finely graduated list of every CVE. The earlier SSVC framework also distinguishes stakeholders and recognizes that items in the same priority category can be scheduled according to operational convenience (Spring et al., 2021).

I would adopt an explicit decision policy, then preserve a separate execution schedule. The policy establishes urgency from the available evidence and organizational obligations. The schedule accounts for staffing, dependencies, testing and change windows. If an urgently required patch is not ready, urgency remains visible while a temporary treatment and escalation are arranged. Reclassifying it as low priority because the owner cannot deploy it tonight confuses difficulty with importance.

For an organization developing its own procedure, I propose the following decision record. It is not a replacement SSVC specification or a new universal scoring standard.

Decision	Evidence to retain	Consequence for the next action
Does this instance match the affected scope?	Product, artifact/version, configuration and advisory or VEX identity	Exclude only with justified scope; otherwise investigate applicability
Is exploitation established or locally suspected?	Dated KEV, supplier, threat or incident evidence	Escalate applicable exposure; assess incident-response needs separately
What path and consequence are credible?	Reachability, permissions, dependencies, service and safety effects	Determine urgency within the organization's policy
Which response is feasible now?	Fix availability, tested workaround, owner, change and recovery constraints	Begin containment or remediation with explicit residual exposure
What would change or close the decision?	Verification criteria, next review, invalidation triggers	Reopen on changed facts; close only within verified scope

This record creates an auditable argument without demanding certainty that the evidence cannot provide. The security team should own the analytical method; service owners supply operational consequences and change constraints; an authorized risk decision maker resolves significant residual exposure. The arrangement can be lightweight. Its value lies in making disputed assumptions visible before a priority label conceals them.

Keep current policy obligations separate from a local score

Policy sources age too. On June 10, 2026, CISA issued BOD 26-04, which supersedes and revokes BOD 19-02 and BOD 22-01. Its prioritization variables include public exposure, KEV status, exploit automation and technical impact. The directive has defined scope and phased implementation requirements; it is not a universal private-sector patching timetable (CISA, 2026). An article that simply repeats the older directive as the current authority can mislead the team using it to justify a deadline.

I would maintain applicable obligations as explicit constraints alongside the technical decision. Record the source, scope, effective phase, triggering event and accountable interpreter. Do not assume that every date shown in a vulnerability feed applies identically to every asset or organization. Equally, do not assume that a locally preferred risk model can extend a binding obligation. Organizations outside the directive's scope can learn from the structure without representing that they are legally bound by it.

This distinction also protects the analysis from becoming a compliance shortcut. Meeting a deadline does not prove that the service was uncompromised before remediation. A deadline is the latest permitted point under a particular rule, not necessarily the best moment to act. The practical question remains whether the organization needs faster containment, investigation or a different service configuration given its evidence.

Make uncertainty a reason for action, not a zero

A useful queue needs to preserve uncertainty about applicability, reachability and controls. CISA's 2022 SSVC guide does not provide an “unknown” decision-point value; it describes selecting the most reasonable assumption using historical evidence. The broader SSVC work describes communicating sets of possible states when information is incomplete (CISA, 2022; Spring et al., 2021). Those are distinct approaches. My proposal is to retain uncertainty in the supporting record even when the chosen operational tree requires a single value.

I would then ask whether resolving the uncertainty could change the action. Suppose an appliance is definitely affected and exploitation is established, but public reachability is disputed. If the two plausible states lead to different urgency, verifying reachability becomes urgent work. If both states require the same immediate treatment, further analysis should not delay that treatment. This is a qualitative value-of-information test, not a calculated financial optimization.

An uncertainty record should name the missing fact, the plausible alternatives, the evidence needed to distinguish them, the person acquiring it and the temporary decision. It should also identify when the team will act without that evidence. Otherwise, “investigating” becomes a way to leave severe exposure unowned. A conservative interim action can be justified by consequence and uncertainty without falsely declaring the worst case proven.

Evidence can also expire through events rather than elapsed time. A previously unreachable feature may be enabled during a release; a supplier may revise the affected range; a mitigation may be removed to restore functionality. I would attach reevaluation triggers to those assumptions. A scheduled review is a backstop, while configuration and advisory changes should reopen the decision when they occur. Confidence belongs to a particular claim and evidence date, not permanently to a green status.

Why multiplying CVSS by EPSS does not calculate your risk

It is tempting to multiply severity by exploit probability and sort the result. The arithmetic is easy; its interpretation is not. CVSS Base is a severity score rather than a monetary consequence, and EPSS concerns observed exploitation for a CVE rather than the probability of a loss event on one asset. Their product can be a chosen ranking heuristic, but calling it expected organizational loss adds assumptions that neither input supplies.

NIST SP 800-30 distinguishes quantitative, qualitative and semi-quantitative assessment and requires clarity about the factors and relationships used. It also explains how hidden subjective assumptions and uncertainty can weaken apparently quantitative results (Joint Task Force Transformation Initiative, 2012). I would therefore require any composite score to declare what decision it supports, how its weights were selected and how overrides work. A reproducible policy index can be useful without being presented as a calibrated risk estimate.

The denominator matters as much as the formula. A vulnerability-level forecast is not automatically the per-instance compromise probability for each of a thousand machines. Those machines may share exposure and controls, and attack events may be dependent. Summing duplicated scores across assets or using an independence formula can produce authoritative-looking results while answering a different question. Such calculations require an explicit event model and justified assumptions before they can support portfolio loss claims.

For most operational queues, I would start with transparent categories and use finer ranking only where it changes scheduling usefully. Even then, I would examine sensitivity. If a small uncertain change in one input reverses the order, the decimal should not settle the dispute. Record the tradeoff, gather decision-relevant evidence, or treat the items as equivalent priority. Precision is valuable when it represents knowledge; otherwise it merely makes disagreement harder to see.

A worked queue with four different next actions

The following examples are invented. The labels do not identify real CVEs, and the scenarios are not measured outcomes. Their purpose is to show why a defensible queue often contains several kinds of work rather than one universal patch order.

Instance	Evidence in the hypothetical case	Immediate decision
A: critical-rated library finding	Exact artifact inspection and a matching supplier statement establish that vulnerable code is absent	Close this applicability finding with evidence; retain change triggers
B: moderate-rated remote-access service	Affected release, established exploitation, public reachability, consequential access and no verified mitigation	Begin urgent exposure reduction and evaluate compromise evidence while preparing the fix
C: high forecast on an internal build service	Affected component; uncertain route from ordinary users; access to production signing operations	Investigate the disputed path immediately and restrict unnecessary access while planning remediation
D: affected availability component	No established exploitation; low forecast; service loss could disrupt a critical process; update needs coordinated testing	Obtain operational/safety input and arrange controlled treatment; do not infer low consequence from the forecast

B is the clearest immediate exposure-reduction task under the stated facts. A should not consume the same emergency change slot merely because its original scanner label was critical. C needs a short investigation that can materially alter its urgency. D demonstrates why lower exploitation evidence does not settle the consequence question. If additional facts reveal an imminent safety concern, the action for D changes; the table deliberately does not pretend that the initial record supplies every fact.

A requires particular discipline. Its closure applies to the inspected artifact and matching statement, not every product containing the library. If a new build includes the vulnerable code, reopen the finding. B may require both remediation and incident investigation; successful patch installation cannot establish that an earlier intrusion did not occur. C's investigation should have an owner and decision time, while D's operational review should identify available interim measures rather than simply defer the issue to the next annual outage.

The example also separates urgency from labor allocation. A network engineer may contain B while an application engineer investigates C and a process owner prepares D's change. A single globally sorted ticket list can hide these parallel opportunities. I would schedule against the actual teams and dependencies, while keeping the decision basis consistent across them. This is a proposal for coordination, not evidence that parallel work is always available or that every organization has spare capacity.

Treat the risk now and prove the eventual repair

NIST SP 800-40 Rev. 4 describes several risk responses, including mitigation through patches or additional controls, avoidance through removal of exposed capability, and explicit acceptance. It separates implementing a response from verifying and monitoring it (Souppaya & Scarfone, 2022). I would use those distinctions to prevent a delayed patch from becoming a choice between uncontrolled exposure and an unsafe emergency deployment.

The immediate response might restrict an interface, disable a vulnerable feature or withdraw a service. Each has operational consequences and residual exposure. The record should say which behavior is prevented and which remains possible, who authorized the tradeoff, and how it will be checked. Detection can support the response but does not silently become equivalent to prevention. If a control only produces an alert, the decision still depends on whether someone can respond before unacceptable harm.

Patch readiness needs its own evidence: compatible release, representative testing, dependencies, recovery options and a responsible change owner. Installing an update may require a restart, reboot, redeployment or configuration change before it takes effect; NIST explicitly distinguishes deployment verification from ongoing monitoring (Souppaya & Scarfone, 2022). I would check the running state, not merely the update job's exit code, and confirm that the affected business function still works after the change.

Verification should match the closure claim. A package-version check may support “this package was updated”; it does not automatically support “every running instance is repaired.” A clean authenticated scan covers the systems it actually assessed, not missing or unreachable assets. For a temporary workaround, verify the intended restriction and monitor the assumptions that keep it effective. If unresolved exposure is accepted, use a separate security-exception closure process so that approval expiry, implementation and technical remediation remain distinguishable.

Test the decision method against its own failure modes

The strongest objection to contextual prioritization is that it can become a sophisticated excuse not to patch. Every owner can argue that their system is unusual, their change window is difficult and their exposure is limited. I would answer that objection with evidence requirements and reviewable overrides. A lower-priority decision needs an attributable reason, a defined scope and a trigger for reconsideration. Unsupported reassurance should not receive the same treatment as a verified constraint.

The opposite objection is also valid: detailed analysis can cost more than deploying a low-risk routine update. I would not require a bespoke assessment for every ordinary patch. Automate well-understood recurring work and reserve deeper analysis for cases where conflicting evidence, consequence or change risk could alter the action. The SSVC distinction between response categories and fine-grained ordering supports that practical division, while the organization's own operating experience must determine how much analysis it can sustain (Spring et al., 2021).

To evaluate the method, I would propose reviewing a bounded sample of past decisions using the evidence available at each decision time. Ask whether different reviewers reach the same response category, which missing facts alter the result, and whether overrides have documented reasons. Separately measure time to ownership, time to verified exposure reduction, unresolved high-consequence instances and expired mitigations. These are proposed evaluation measures; this paper has not run that study or established a reduction in incidents.

The method's limits are substantial. It depends on inventory quality, trustworthy supplier evidence, timely threat information and service owners who can explain consequences. It cannot quantify hidden compromise, prove every attack path absent or compensate for an organization unable to execute its decisions. Public research and guidance support the distinctions made here; they do not validate the local thresholds, staffing assumptions or control effectiveness of a particular organization.

I would judge a vulnerability program by whether it can explain its next action and verify the result. If your queue cannot explain why an exploited gateway is waiting behind an irrelevant critical finding, I can help assess the decision process: trace a sample from advisory through asset matching, prioritization, change and closure; identify where evidence or ownership breaks; and define practical acceptance criteria for improvement. Request a vulnerability-management assessment to examine that chain in your environment. The useful deliverable is a defensible remediation decision, not another unexplained score.