A new CVE lands in your inbox. The subject line says critical, the CVSS score is 9.8, and someone from leadership has already forwarded it asking, "Are we affected?" You have maybe twenty minutes before the thread grows more people than answers. What follows is the order of operations that stops a routine triage from turning into a week of guesswork.

Start With the Advisory, Not the Headline

Before you touch a scanner or open a ticket, read the actual advisory. CVE descriptions are often terse, and the summary you saw on social media is frequently a paraphrase of a paraphrase. Open the NVD entry, the vendor advisory, and the CNA's original writeup if one exists.

You are looking for four things:

• Affected product and version range. "Version 3.x before 3.4.2" is useful. "Multiple products" is not, and you should note that gap for later.
• Attack vector. Network, adjacent, local, or physical. This single field does more to shape your urgency than the base score.
• Privileges and user interaction required. An unauthenticated network exploit is a different animal from one that needs an authenticated admin to click something.
• Known exploitation status. Check whether it has been added to CISA's Known Exploited Vulnerabilities catalog. If it has, treat the timeline as urgent regardless of your initial exposure read.

Write these down in the ticket as you go. Future you, and whoever inherits the ticket, will thank present you for the citation trail.

Confirm Whether You Actually Run the Thing

This is where most triage mistakes happen. Teams either assume they are affected because the product name sounds familiar, or assume they are safe because "we don't use that." Neither assumption survives contact with a real asset inventory.

Check the inventory, then check again

Query your CMDB, your vulnerability scanner, your endpoint agent, and your cloud asset inventory. Ideally these agree. In practice they rarely do, so reconcile the differences before drawing conclusions. A component bundled inside a larger application will not show up as a standalone install, and container images often carry dependencies that never appear in a host-based scan.

Look for transitive and embedded copies

If the CVE is in a library, search your dependency manifests. A vulnerable logging library can sit three levels deep in a Java application and still be reachable. Run a software composition analysis pass if you have one; if you don't, grep your lockfiles and container image SBOMs.

Confirm the version, not just the product

Finding the product is half the job. Confirm the installed version falls inside the affected range. Backported patches are common in enterprise Linux distributions, so a version string that looks vulnerable may already carry the fix. Check the distribution's own security tracker before escalating.

Assess Exploitability in Your Environment

CVSS describes the vulnerability in the abstract. Your exposure describes it in your network. The two numbers are related but not the same, and the second one is the one that drives your response.

Ask a short set of questions:

1. Is the affected service reachable from the internet, or only from an internal segment?
2. Does it require authentication, and if so, what kind and at what privilege level?
3. Is there a public proof of concept, a Metasploit module, or observed exploitation in the wild?
4. Are compensating controls in place — a WAF rule, network segmentation, an endpoint detection rule, or a disabled feature?
5. What is the blast radius if it is exploited? A single workstation is not the same as your identity provider.

If a public exploit exists, do not wait for a scanner to confirm. Reproduce the exposure path manually if your change control allows it, in a lab, and document what you find. Reproducing the path is often faster than tuning a scanner plugin and gives you far more confidence in the result.

Score the Business Impact, Not Just the Technical One

Technical severity gets you to the front of the queue. Business impact decides what happens when you get there. A medium-severity flaw in a system that processes regulated data or supports a revenue-critical workflow can outrank a critical flaw in a lab box nobody depends on.

Bring in the people who own the system. Ask what it does, who depends on it, what data it touches, and what a two-hour outage would cost. If the patch requires a maintenance window on a system with strict availability requirements, that constraint belongs in the ticket now, not the day before the change.

Document the decision, not just the outcome. "We are not patching this quarter because the affected endpoint is behind authentication and network-isolated, and the vendor fix breaks our integration" is a defensible position when it is written down and reviewed. The same decision made silently is an audit finding waiting to happen.

Choose and Document the Remediation Path

Not every CVE ends in a patch. Your options are usually some combination of the following, and each one needs an owner and a date.

• Patch or upgrade to a fixed version. Note the target version and the change window.
• Apply a vendor workaround such as disabling a feature, changing a configuration default, or rotating credentials.
• Add compensating controls — a virtual patch on the WAF, a detection rule, or tighter network segmentation.
• Accept the risk with a documented rationale and a review date, signed off by the system owner.
• Retire the component if it is end-of-life and no fix is coming. Sometimes decommissioning is the cheapest fix available.

Set a due date based on exposure and impact, not on how inconvenient the change is. Then close the loop: verify the fix after deployment, rescan, and update the ticket with evidence. A patch that was applied but never verified is a note in a system, not a remediated finding.

The Triage Record That Saves You Later

Keep one ticket per CVE that links everything: the advisory, the affected assets, the exposure assessment, the decision, the owner, and the verification result. When the next CVE arrives — and it will, probably before lunch — you will have a template and a habit instead of a scramble. Triage is mostly disciplined reading and honest documentation. The tools help, but the order of operations is what keeps you fast.

Photo: AlphaTradeZone / Pexels