Can a safe vulnerability alert become dangerous later? Five changes

Yes. An alert you marked safe can turn urgent later. Attackers may start using the flaw, your code may begin to call it, a setting may switch on, the service may become reachable from the internet, or the advisory may be corrected. A "no action" decision holds for the facts of that day and no longer.

TL;DR

• "Not a risk today" is a statement about today. Facts change.
• Five changes flip most alerts: new exploitation, new code, new settings, new exposure, new advisory details.
• Give every "no action" decision a date, an owner and a recheck trigger.
• Automatic rechecks beat memory. Set them up once and let them run.

Definition: recheck trigger. A named event that sends a closed alert back for review, such as "a new public route is added" or "this flaw appears on the CISA Known Exploited Vulnerabilities list." It turns a one time decision into a living one.

Why does a "safe" decision go stale?

Imagine you lock your shed because someone said thieves were not in your area. Then a thief is caught three streets away, you buy a new tool and move it into the shed, and a neighbor tears down the fence. Your lock decision was fine in the morning. By the weekend it was not, and nothing about the lock changed.

Vulnerability decisions behave the same way. When you close an alert as "not reachable" or "low risk," you are combining several facts: what attackers are doing, what your code does, how your system is set up, who can reach it, and what the advisory says. If any one of those facts changes, the answer can change.

The US Cybersecurity and Infrastructure Security Agency (CISA) builds this idea into its own rules. In its directive BOD 26-04, it says the remediation timelines for each asset are dynamic as facts change. It gives an example: removing a system from the internet changes its exposure and moves the required timeline out, while a new entry on the KEV catalog shortens it. The same logic applies to your own decisions inside a company.

What are the five changes that flip an alert?

1. Attackers start using the flaw. Security researchers describe the state of exploitation in three steps. The SSVC framework, a public decision method, lists them as none (no evidence of exploitation and no public proof of concept), public proof of concept (working example code exists in places such as Metasploit or ExploitDB, or the method is well known), and active (reliable, public evidence that real attackers are using it). A flaw can move from the first step to the third in days. The CISA KEV catalog is where CISA lists flaws seen in real attacks, and EPSS, the score that estimates the chance of exploitation in the next 30 days, is published daily for every CVE. Both can change your answer overnight.

2. Your code changes. Today the risky function is never called. Next month a developer adds a feature that uses it. Reachability results are tied to a specific version of your code. They need to be rerun when the code changes, since a result about a past build speaks for that build alone.

3. A setting or feature flips on. Many flaws matter just when a feature is enabled. If you closed the alert because the feature was off, switching it on reopens the question. The CVSS standard even instructs that when a flaw requires a specific configuration, it should be scored as if the product were in that configuration, which tells you the published score does not promise your setup is safe.

4. Exposure grows. An internal tool gets a public address. A test service is cloned into production. A partner is given access. A flaw that no outsider could reach is now open to the internet. CISA's BOD 26-04 treats whether an asset is publicly exposed as one of the four key variables in setting urgency, and defines "publicly exposed" as reachable by unauthenticated or untrusted parties over public networks.

5. The advisory changes. Advisories are living documents. Maintainers may add more affected versions, more affected functions, or a better description of the conditions. A flaw first described as needing a rare setup may later turn out to work in the default setup. If you closed the alert based on the first description, you need to see the update.

What does a flipped alert look like in practice?

Here is a worked example. The names and numbers are invented to illustrate the idea.

A team closes an alert for a file parsing library on 3 March. Their note says: "Library flaw lets crafted files crash the parser. Our app never parses user files. Not reachable. Recheck if we add uploads." Score 7.5, not on KEV, EPSS low (invented as 0.02). Decision: no action.

On 12 May the product team ships a profile photo feature. Files from users now go through the parser. The recheck trigger "we add uploads" is in the ticket, but nobody on the product team reads that ticket. Two weeks later a public example exploit appears and EPSS jumps (invented as 0.40). The flaw now sits behind a public upload button with a high prediction of attack.

If the team has no automatic recheck, this stays closed until an incident or an audit. If they do, the next scan after the merge reruns reachability, sees the new call path, reopens the alert, and sends it to the owner with the new facts. The fix is a small upgrade and ships in a day.

The lesson is not that the first decision was wrong. It was right on 3 March. The lesson is that the decision needed a way to wake up.

How do you keep decisions from going stale?

Follow these steps.

1. Write the reason, not just the verdict. "Not reachable" is a verdict. "Parser is used in the nightly import, which reads our own files" is a reason. Reasons can be checked later.
2. Add a date and an owner. A decision without a name is a decision nobody will revisit.
3. Name one or two triggers. Pick events that your team can see, such as new routes, new feature flags, or new dependency versions.
4. Rescan on a schedule. A clean scan at build time is a snapshot. Rescan daily or weekly, even when nothing in your code changed, because the world outside your code does change.
5. Rerun reachability on every merge that touches code paths. Do it in the pull request check so the person making the change sees the result at once.
6. Watch the outside signals for your open and closed alerts. Check KEV and EPSS changes against the full list, not just the open items. A closed alert that gains a KEV entry should reopen on its own.
7. Review closed alerts every quarter. Sample a few and test whether the reason still holds.

If you do one thing, do step 6. It costs almost nothing and catches the most dangerous flip, the one where attackers have started to use a flaw you closed.

What can Safeguard do to catch these changes?

Safeguard keeps scanning after the first scan. Zero-day discovery matches new advisories to the component versions in your projects and ranks them, so the urgent ones come first. Reachability analysis traces your call paths into vulnerable functions, and you can run it again as your code changes. Its SBOM and dependency scanning keep the list of pieces in your product current, and policies and gates let you set rules for what blocks a pull request.

Autonomous remediation with fix pull requests exists too. It is off by default and every category starts on Manual, so a person turns it on and chooses which kinds of changes run without review. You can start with a free scan at gold.safeguard.sh/scan.

For related reading, see runtime versus build time SBOMs and reachability analysis questions and answers.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how a new advisory is matched to the component versions in a project and how the list is ranked so the urgent items come first.

Quick check

Sources

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

Last reviewed: 19 October 2026.