How to Triage a Vulnerability Alert

A vulnerability alert is a prompt to check whether a reported issue matters to your own systems. A high score alone does not tell you what to fix first. Start with the vendor’s affected versions, then check where the asset runs and whether there is evidence of exploitation.

For the meaning of vulnerability intelligence, see the glossary. This article follows one alert through a practical triage decision. For the wider cycle, see the vulnerability management guide.

1. Check the Source and Affected Versions

Find the vendor advisory and record its date, affected products, versions, fixed versions and any listed conditions. If the alert names a CVE, use that ID to match records across sources. A CVE is a reference, not proof that your own system is affected.

Check whether you run the affected product and version. If inventory is incomplete or the version cannot be confirmed, keep the finding open as unknown and assign someone to check it. Do not mark it safe simply because a scan did not find it.

2. Check Exposure and Threat Evidence

Ask where the system is reachable, who can access it and what service or data it supports. An internet-facing service and a restricted test system may need different responses. Existing controls matter, but record what they cover and how you verified them.

Check the CISA Known Exploited Vulnerabilities catalog and the vendor’s updates for evidence of exploitation. A catalog entry is evidence that exploitation has been observed in the wild; it does not establish that your own system was compromised. If there are signs of compromise, follow your incident response process as well as fixing the vulnerability.

3. Use Scores as Inputs, Not the Decision

A CVSS Base score describes technical severity. FIRST explains that it is not a complete measure of risk for a particular organization. Combine it with exposure, affected assets and threat evidence.

EPSS is an estimate of the chance that exploitation activity will be observed in the wild within the next 30 days. It is not a prediction that your system will be attacked or a measure of impact. The FIRST EPSS FAQ explains these limits. A missing score is a data gap, not a zero-risk finding.

4. Record a Decision and Check It Again

Choose a fix, a temporary control or a documented reason to defer. Name an owner, set a review time and record the source and version used for the decision. If no fix is ready, limit access or apply a vendor-recommended workaround where suitable, then verify the control and revisit the finding.

After a patch or change, check that it applies to the affected asset and that the relevant issue is resolved. Keep the evidence with the record. A change in vendor advice, asset exposure or exploitation evidence can change the priority.

A Small Worked Example

Imagine an alert for a flaw in a service. The vendor says one installed version is affected, but the team cannot yet confirm the version on a public-facing server. The first action is to verify the version and exposure, not close the alert.

If the version is affected and exploitation is confirmed in the wild, the team can assess an urgent fix or temporary control against the service’s role and access. If the version is not affected, record the evidence and close that finding. These are example choices, not a fixed rule for every system.

Where Brandefense Fits

Brandefense brings together Cyber Threat Intelligence, Digital Risk Protection and External Attack Surface Management. Its vulnerability intelligence page describes the product. A team still needs to confirm its own assets and decide how to respond; no source guarantees an alert before exploitation or coverage of every vulnerability.