Responding to a Critical CVE Without Triggering a Flood of False Positives

A severity score is not a routing decision

Last year, a Critical CVECommon Vulnerabilities and ExposuresA standardized identifier for a publicly disclosed cybersecurity vulnerability. hit the wire on a Thursday afternoon. Within two hours, three teams had started emergency patching. Two of them were working on services where the affected library was not even reachable from production code paths. I’ve seen this pattern too many times: a severity score triggers a blanket response, and half the remediation effort burns on services that were never at risk.

The problem is not urgency. The problem is that urgency without evidence creates two failure modes at once: real risk sits unowned while your teams chase phantom matches.

What a useful response looks like

The first useful outcome for any critical CVE is a bounded, reviewable decision for each affected service: remediate, investigate, deprioritize with evidence, or unknown. This lets you act fast where evidence supports action, without silently treating incomplete evidence as safety.

The CVE Program assigns identifiers and maintains a process for publicly known vulnerabilities; it does not determine your local risk or remediation priority. CVSS v4.0 communicates severity, but its specification separates base severity from threat and environmental metrics. A Critical CVSSCommon Vulnerability Scoring SystemA standardized framework for rating the severity of security vulnerabilities on a numerical scale from 0 to 10. value is triage input, not a substitute for service-level context.

This diagram is a Kurio Nova operating model synthesized from the sources cited in this article, not a standard or a scoring engine. The full model is developed in From SBOM to Actionable Signal. It shows evidence links, not a fixed order. A VEXVulnerability Exploitability eXchangeA security advisory that communicates whether vulnerabilities affect a specific product and why. cannot prove a workload is running; a runtime observation does not establish reachability; a component match does not show that the affected code can execute.

The per-service checklist

I’ve run variants of this checklist in three organizations. The ones that worked shared a trait: they forced you to state what you did not know, not just what you did.

Run it once per service and deployment scope. Building a DevSecOps Evidence Chain provides the full end-to-end walkthrough. The goal is to leave a record another engineer can reconstruct.

1. Preserve the vulnerability record

• Record the CVE identifier, source URL, publication and update timestamps, affected versions, and any available CVSS vector.
• Check whether the issue appears in the NVD vulnerability detail pages and in CISA’s Known Exploited Vulnerabilities Catalog.
• Record each source’s state as-is: a CVE entry, NVDNational Vulnerability DatabaseA NIST-maintained repository of vulnerability management data that provides analysis, scoring, and enrichment for published CVEs. enrichment, and KEVKnown Exploited VulnerabilitiesA CISA-maintained catalog of vulnerabilities confirmed to be actively exploited in the wild, used to prioritize remediation. inclusion answer different questions.

The CVE Program process covers assignment and publication. NVD provides analysis and enrichment. CISACybersecurity and Infrastructure Security AgencyThe United States federal agency responsible for cybersecurity guidance, vulnerability coordination, and critical infrastructure protection.’s KEV Catalog identifies vulnerabilities known to be exploited in the wild. KEV inclusion is strong prioritization context, but it does not tell you which of your services are affected.

Decision boundary: do not route from severity alone. If you cannot yet identify the service scope, route the record to investigate or unknown, with an owner and a next evidence request.

2. Establish what your inventory says and what it cannot

• Match the advisory’s package and version criteria to the service’s SBOMSoftware Bill of MaterialsA machine-readable inventory of the components and dependencies included in a software product..
• Retain the SBOM reference, issuer, generation time, component identity, declared coverage, and known unknowns.
• If the component cannot be reliably matched, retain that uncertainty. Do not call the service unaffected.

CISA’s SBOM minimum-elements guidance addresses coverage and known unknowns. An SBOM match is inventory evidence, not a security decision. It does not establish that the component is present in the running workload, that the inventory is complete, or that vulnerable code is reachable.

Decision boundary: an SBOM match creates a candidate affected service. A missing or incomplete match is not proof of absence.

3. Bind inventory to an immutable artifact, then observe deployment

• Record the OCIOpen Container InitiativeA governance structure for open standards around container formats, runtime specifications, and image distribution. digest and object type used to bind the affected artifact.
• Record both the intended image reference and an independently collected runtime observation, with workload, environment, collection method, and observation time.
• If you cannot establish the exact deployed identity, keep the service outcome unknown or route it to investigate.

The OCI image descriptor specification defines a digest as a content identifier. This makes a digest a useful join key, unlike a mutable image tag. It does not prove what is running, where, or whether it is vulnerable in context.

Kubernetes allows images to be specified by digest and describes pull and update behavior in its container image documentation. That is platform-specific, not universal runtime proof. Retain the observation time because deployments change.

Decision boundary: content identity is not runtime proof. A digest and a runtime observation are separate records that must be joined deliberately.

4. Add supplier context without using it as a suppression switch

• If a VEX exists, retain issuer, product and version match, status, justification, release date, and revision history.
• Confirm that the VEX statement applies to the product and version in scope before relying on it.
• Route a VEX with no applicable match, missing justification, or unresolved status to investigate or unknown.

The CSAF VEX 2.1 specification defines machine-readable vulnerability status communication for products and includes document tracking. A VEX is attributable supplier context, versioned and auditable. It is not a timeless guarantee, and it does not establish local deployment, configuration, or reachability. For a deeper look at each justification flag, see VEX: Documenting “Not Exploitable”.

Decision boundary: known_not_affected supports a documented local assessment only when its product/version applicability and justification are retained. It is not an unaudited suppression.

5. Bound local exposure and reachability

• State the service’s relevant entry points, configuration assumptions, and compensating controls, if assessed.
• State the method used for reachability analysis, its scope, and what it did not cover.
• Reopen the record when a configuration, deployment, exposure, or analysis change invalidates those assumptions.

Reachability helps you prioritize, but the evidence is bounded by its method. A study on Java dependency reachability showed that static and dynamic analysis each miss what the other catches. When you are triaging a critical CVE, that means a single reachability pass cannot close the question on its own.

Decision boundary: no observed path is not proof of safety; a reachable path is not proof of practical exploitation. Both are context for accountable review.

6. Select and record one outcome

Choose one outcome for the named service, not for the CVE in the abstract. These are local workflow states, not universal classifications.

Outcome	Use when	Minimum record
Remediate	The service maps to an affected deployed artifact and the local review supports action.	Owner, target artifact or mitigation, target date, verification plan, reassessment trigger.
Investigate	The service is a credible candidate, but a material join or assessment is pending.	Evidence request, owner, due date, and explicit question to resolve.
Deprioritize with evidence	Applicable, attributable assessment and local context support a bounded lower priority.	Evidence and justification, decision owner, expiry, and reopening events.
Unknown	Required evidence is missing, stale, contradictory, or not assessed.	Missing evidence, owner, next collection step, and reassessment trigger.

NISTNational Institute of Standards and TechnologyA United States federal agency that develops cybersecurity standards, guidelines, and vulnerability data infrastructure.’s Guide to Enterprise Patch Management Planning frames patch management as an organizational process that includes planning and implementation. Use the outcome record to connect a technical finding to that accountable process.

A record a reviewer can replay

finding:
  cve: CVE-2024-38816
  source: https://nvd.nist.gov/vuln/detail/CVE-2024-38816
  cvss_v4: "9.1 / CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N"
  nvd_checked_at: 2026-08-03T09:10:00Z
  kev_checked_at: 2026-08-03T09:10:00Z
service_scope:
  service: payments-api
  environment: production
inventory:
  sbom_ref: evidence://payments-api/sbom/2026-08-03
  component: pkg:maven/org.springframework/spring-webmvc@6.1.12
  coverage: "declared by issuer; known unknowns retained"
artifact:
  digest: sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
  object_type: oci-image-manifest
runtime:
  intended_ref: registry.internal/payments-api@sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
  observed_at: 2026-08-03T09:20:00Z
  observation_method: independently-collected-runtime-observation
context:
  vex: "no matching statement retained"
  reachability: "not yet assessed"
decision:
  outcome: investigate
  owner: payments-api-service-owner
  question: "Does the observed artifact contain the affected spring-webmvc version, and is the path traversal vector reachable from production entry points?"
  due: 2026-08-04
  reassess_on:
    - runtime identity update
    - new VEX revision
    - completed reachability analysis

The record does not jump from Critical to remediate. It has a candidate component match and a runtime observation, but it still lacks a confirmed component-to-artifact join and reachability assessment. Investigate preserves urgency while making explicit what has not been shown. If you cannot obtain the required evidence, the honest result is unknown, not a silent closure.

Reassessment is part of the decision

I think this is where most teams break down. They make a sound decision on day one, then never revisit it. A deprioritization without an expiry date is just a suppression with better formatting.

Reopen the record when any retained evidence changes:

• A revised CVE, NVD analysis, or KEV catalog state
• An SBOM, artifact digest, or deployment observation change
• A new or revised VEX statement
• A configuration or exposure change
• Improved or contradictory reachability analysis

Ownership must be explicit. You own the decision and its expiry. The build, platform, security, or supplier contacts own their evidence updates. Assigning one person to “own security” does not make each evidence source current.

What this workflow does not prove

This checklist improves traceability. It does not eliminate false positives, guarantee remediation speed, or prove exploitability or safety.

• CVSS severity is not local risk.
• An SBOM match and an artifact digest tell you what was built, not what is running.
• VEX is attributable, versioned supplier context, not a permanent exemption.
• Reachability assessment is bounded by its method and coverage.
• The four-outcome model is a local synthesis; your team needs its own thresholds, escalation paths, and governance.

The next time a Critical CVE lands in your queue, run this checklist for one service before you apply a global disposition. If a second reviewer cannot identify the exact evidence, decision owner, unknowns, and the event that will reopen the record — the decision is not done yet.