Why do most vulnerability alerts need no action? Five reasons

Most vulnerability alerts need no action because the flagged problem cannot hurt your software as you actually run it. The risky code may never be called, a needed setting may be off, an attacker may have no way in, the match may be wrong, or a fix may already be in place. Each alert still deserves a quick, written check.

TL;DR

• A scanner alert says a flaw is known in a version you use. It does not say you can be attacked.
• Five reasons explain most alerts that need no action: not called, conditions not met, no way in, wrong match, already handled.
• "No action" must be a decision with evidence, not a shrug.
• A short check on each alert, repeated over time, is how teams cut a long list to the few items that matter.

Definition: vulnerability alert. A message from a scanning tool saying that something you use matches a published, known flaw. The tool compares names and version numbers against a database. A match means "this version is on the list." It does not mean "this flaw can be used against you."

What does a vulnerability alert actually tell you?

Think of a recall notice for a car model. The notice says that cars of a certain model and year have a faulty part. It does not say your car is on fire. You still check whether your car has that part, whether the part is the faulty batch, and whether it has already been replaced.

A vulnerability scanner works the same way. It reads the list of software pieces your product uses. For each piece it asks a database: is this exact version known to have a flaw? If yes, it raises an alert. It does this fast and at scale, which is useful. It also means the scanner is working from a list, not from how your software behaves.

The US standards body NIST defines a vulnerability as a weakness that "could be exploited or triggered by a threat source." The key word is "could." Whether it can be, in your product, is a separate question. The group behind the OpenVEX format says the same thing from the scanner side. It notes that software is often not affected even when a scanner flags it: the vulnerable component may already be patched, may not be present, or may not be able to be run.

There is also a base rate worth knowing. FIRST, the group that maintains the EPSS exploit prediction score, states in one of its articles that around 5% of all vulnerabilities are ever exploited in the wild. That figure comes from research it cites, and the article used data as of March 2022, so treat it as a rough guide. The point holds: most published flaws never become attacks.

What are the five reasons an alert needs no action?

Here are the five. Each one is a different way the gap between "listed" and "harmful" shows up.

1. The vulnerable code is never called. A software package is like a toolbox. A flaw may sit in one tool you never pick up. If your program never calls that part, an attacker has no path to it. This is the idea behind reachability analysis, which traces how your own code reaches into the package.

2. The conditions for the attack are not met. Many flaws work just when a certain feature is on, a certain setting is chosen, or certain input is accepted. If your product runs with that feature off, the flaw sits idle. The CVSS scoring standard even tells scorers to assume the risky configuration when a flaw needs one, which means the published score may assume a setup you do not have.

3. An attacker has no way to reach it. Some flaws need a network connection from the internet, some need a login, some need someone to sit at the machine. If the affected piece runs deep inside your system and no outside input reaches it, the risk is lower. Lower is not zero, because attackers who get inside can move around, but it changes how fast you must act.

4. The match is wrong. Scanners sometimes match on a name and version that look right but are not. A vendor may have patched the old version number without changing it (called a backport). A fork may share a name with the original. A package may be listed in a file but never installed. In these cases the alert is a false positive, meaning a report of a problem that is not there.

5. It is already handled. A fix may have shipped since the last scan, a firewall rule may block the path, or the feature may have been removed. The alert is out of date, or the risk is covered by another step.

Does "no action" mean you can ignore the alert?

No. "No action" should be a decision, written down with its reason, and open to change. Three traps catch teams who skip that discipline.

The first trap is the wrong "never called." Code can be called in ways a quick search will not find, such as through plugins or by name at run time. Analysis tools can say "unknown" for these cases, and unknown is not the same as safe.

The second trap is the stale decision. A reason that was true in March may be false in June. A developer adds a feature, a setting gets flipped, or a new route opens to the internet. A decision with no date and no owner cannot be rechecked.

The third trap is the missing record. If an auditor, a customer or a new teammate asks "why did you not fix this?", the answer should be a sentence with a link, not a memory. The OpenVEX approach exists for this reason. It gives suppliers a standard way to state that a product is not affected by a given flaw, along with a reason.

How do the five reasons look on a real list?

Here is a worked example. The numbers are invented to show the idea. They are not from a real customer or study.

A small team scans one web service and gets 240 alerts. They sort each alert into the first reason that fits.

That leaves 60 alerts, one quarter of the list. Of those, suppose 12 turn out to be urgent: called by the code, reachable from the internet, with a public exploit. The team now has a short, defensible queue. They also have a record of the other 180 decisions.

The same team would have burned weeks if they treated all 240 alerts the same. They might also have lost the urgent 12 in the pile, which is the real danger of a long list. People stop reading it.

How do you check one alert in ten minutes?

Use this routine. It works on paper, in a ticket, or in a spreadsheet.

1. Write down the facts. Note the package name, the version you run, the flaw ID, and the version that fixes it. If a fixed version exists and the upgrade is small, you may simply fix it and stop here.
2. Read the advisory summary. Look for words such as "when", "if" and "unless." Those are the conditions. Write them down.
3. Check the conditions against your setup. Is the feature on? Is that setting chosen? Can untrusted input reach the affected piece?
4. Check whether your code reaches the risky part. Use a reachability tool or a code search. Record the result and mark "unknown" honestly if you cannot tell.
5. Check the outside signals. Is the flaw on the CISA Known Exploited Vulnerabilities (KEV) list, which tracks flaws seen in real attacks? What is its EPSS score, the estimated chance of attack in the next 30 days?
6. Decide and write one sentence. Fix now, fix in the normal cycle, or no action with a reason. Add a date and an owner.
7. Set a recheck trigger. For example, "recheck when we add a public API route" or "recheck at the next release."

If you do this on every alert, the list shrinks for real reasons rather than because people gave up.

What can Safeguard do for this problem?

Safeguard scans your dependencies and builds a software bill of materials (SBOM), which is a full list of the pieces in your product. It then runs reachability analysis, which traces your own call paths into each vulnerable function, so your team can see which findings can be reached and which cannot. Safeguard also checks findings against signals such as known exploitation. Policies and gates let you decide what blocks a release and what does not, and the decisions stay on record.

Safeguard offers autonomous remediation with fix pull requests too. It is off by default, and every category starts on Manual, so nothing changes in your code until an administrator turns it on. You can try a free scan at gold.safeguard.sh/scan.

For related reading, see what reachability analysis is, which signal should drive patching and reachability analysis questions and answers.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how a long list of findings shrinks when your own call paths are traced, and notice that the rest of the list is still visible, not deleted.

Quick check

Sources

• NIST CSRC glossary: vulnerability
• OpenVEX specification repository
• FIRST: EPSS probability and percentile article
• FIRST: EPSS overview
• FIRST: CVSS v3.1 specification
• CISA Known Exploited Vulnerabilities Catalog

Last reviewed: 19 October 2026.