Should I fix this vulnerability alert? A five question check

To decide whether to fix a vulnerability alert, ask five questions in order: is it used in real attacks, can an attacker reach it, what would they gain, is a safe fix ready, and can you cut the risk another way. Exploited and reachable means act now. Otherwise schedule it or record why not.

TL;DR

• Severity scores describe how bad a flaw could be in general. They do not say whether you should act today.
• Five questions, asked in a fixed order, give a repeatable answer in about ten minutes per alert.
• The outcome is one of four: fix now, fix this sprint, fix in the normal cycle, or record a reasoned "no action" with a recheck date.
• Write the answer down. The record is as valuable as the fix.

Definition: triage. The word comes from hospitals. It means sorting many cases fast so the most urgent get attention first. In security, triage is sorting alerts into "act now," "act soon," and "watch," using a short, consistent set of questions.

Why is a severity score not enough to decide?

Most alerts come with a number from the Common Vulnerability Scoring System (CVSS), a 0 to 10 scale. Teams often set a rule such as "fix everything above 7." That is easy to follow. It also goes wrong in two directions.

The people who maintain CVSS say so themselves. FIRST, the group that publishes it, states that CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk. Severity is how bad the damage could be. Risk also depends on whether anyone is attacking, whether they can reach the target, and what the target is worth to you.

A high score on a flaw nobody exploits, in code you never call, behind a login, is a loud alarm for a small fire. A medium score on a flaw that attackers are already using against internet-facing systems is a quiet alarm for a real one. A fixed cutoff cannot tell these apart.

So the five questions below add the missing context. They borrow ideas from public work: the CISA Known Exploited Vulnerabilities (KEV) catalog, the EPSS exploit prediction score, and the SSVC decision framework, which CISA says informs the timelines in its directive BOD 26-04.

What are the five questions?

Ask them in this order. The order matters because the early questions are fast and often settle the matter.

Question 1: Is this flaw being used in real attacks? Check whether it is on the CISA KEV catalog. CISA describes the catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and asks organizations to use it as an input to their prioritization. If it is listed, the answer leans toward "fix now." If it is not listed, look at the EPSS score, which estimates the chance a flaw will be exploited in the next 30 days. A high EPSS score is a warning sign. A low score lowers urgency but does not remove it, since EPSS is a prediction and not a promise.

Question 2: Can an attacker reach the vulnerable part? This has two halves. First, does your own code actually use the risky function? That is the reachability question. Second, can outside input get to it? A flaw in code called by just an internal batch job is harder to attack than one in a public web form.

Question 3: What would an attacker gain? CISA's directive BOD 26-04 calls this technical impact. Total control means the attacker takes over the behavior of the software, or reliably reveals login credentials. Partial control means limited control or limited information exposure. CISA's directive BOD 26-04 notes that a denial of service, where the attacker can knock the service offline but not take it over, counts as partial control. Both matter, but they do not call for the same speed.

Question 4: Is a safe fix ready? Is there a fixed version? Is the upgrade a patch, a minor step, or a major jump that could break your product? A fix that is ready and low risk usually wins, even for a modest threat, because it is cheap. A fix that needs a big rewrite might shift your answer toward a stopgap.

Question 5: Can you reduce the risk another way? Options include turning off the affected feature, removing the dependency, limiting who can reach the service, or adding a filter in front of it. These are stopgaps. They buy time and should come with an expiry date.

How do the answers turn into a decision?

Use the first three questions to set the urgency and the last two to pick the action. Here is a simple map.

This is a starting point, not a law. Your business may tighten it. A bank or a hospital may want shorter timelines than a hobby project. What matters is that the same facts always give the same answer, so people do not argue each time.

Notice how the table treats "unknown." If you cannot tell whether code is reachable, the safe move is to treat it as reachable for a flaw that is being exploited. SSVC's own guidance takes the same stance on one of its decision points: if nothing is known about whether an attacker can automate the attack, assume yes.

What does this look like on three real-shaped alerts?

The three alerts below are invented to show the method. The names and numbers are not from a real system.

Alert A. A web framework flaw, listed on KEV. Your public website uses the affected feature. Impact: an attacker can run commands on the server. Q1 yes, Q2 yes, Q3 total. Fix is a minor upgrade. Decision: fix now, today. Write one line: "KEV listed, public route calls affected function, upgrade to the fixed minor version."

Alert B. A date library flaw rated 8.1 on CVSS. Not on KEV, EPSS low. The risky function is used in just one nightly report that runs on staff laptops with no outside input. Q1 no, Q2 no, Q3 partial. The upgrade is a major version jump that touches many files. Decision: record "no action," with the reason and a trigger to recheck if the report ever accepts outside files. Add the date and the owner.

Alert C. An image library flaw rated 6.5. Not on KEV, but EPSS is high. Your product accepts image uploads from users and calls the affected function. Q1 no but high EPSS, Q2 yes, Q3 partial (it can crash the service). Fix is a patch release. Decision: fix this sprint. It is cheap, the path is open, and the signals are warm.

The ranking from the old rule would have put B first because of the 8.1. The five questions put A first, C second, and B last with a record. That is the whole point.

How do you run the check in ten minutes?

Follow these steps for each alert.

1. Open the alert and copy the basics. Package, version, flaw ID, fixed version, and the score.
2. Look up KEV and EPSS. Both are free and public. Note the answer in the ticket.
3. Run or read the reachability result. If none exists, do a code search for the affected function and mark "unknown" when unsure.
4. Decide the impact. Read the advisory summary and write one sentence on what an attacker gains.
5. Check the fix. Note whether it is a patch, minor or major change, and whether tests pass.
6. Pick the decision from the table. Add the date, owner and recheck trigger.
7. Close the loop. When the fix ships, note the version. When the answer is "no action," add the evidence link.

A tip for teams: do the first three steps for all alerts in one sitting, then save your thinking time for the ones that need it. Many alerts settle at question 1 or 2.

What can Safeguard do for this check?

Safeguard brings several of these answers into one place. It scans your dependencies and builds an SBOM, a list of everything in your product. Reachability analysis traces your own call paths into vulnerable functions, which answers question 2. Its exploitability check looks at each finding with evidence for every answer, so you can see which ones an attacker could use today. Zero-day discovery matches new advisories to the versions in your projects and ranks them.

Policies and gates let you turn your decision table into rules, such as blocking a release when a reachable, exploited flaw is present. Autonomous remediation with fix pull requests can handle question 4, but it is off by default and every category starts on Manual, so a person decides when to turn it on. The Safeguard CLI can also write code, which can help with the fix step when you choose to use it, and you review the result like any other change. You can try a free scan at gold.safeguard.sh/scan.

For more background, read CVSS, EPSS and KEV explained, what the CISA KEV catalog is, and why triage is broken and what a better workflow looks like.

Try it yourself

Click through it at your own pace, or open it full screen. Look at the four questions the demo checks each finding against, and at the evidence shown behind every answer.

Quick check

Sources

• FIRST: CVSS v3.1 user guide
• CISA Known Exploited Vulnerabilities Catalog
• FIRST: EPSS overview
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• SSVC: Automatable decision point

Last reviewed: 19 October 2026.