Do not ignore it and do not block forever. Record it as a time limited exception with an owner, a reason, a compensating control, and a review date. Then check each week whether a fix, a replacement, or new exploitation data has changed the picture. An exception is a decision with an expiry.
Why this case is common
Some findings have no fixed version yet. Some fixes need a major upgrade that breaks something. Some libraries are unmaintained. If your gate fails on every such item, teams will demand blanket exceptions. If it never fails, real risk accumulates. You need a middle path with discipline.
Step 1: confirm it matters
Before accepting risk, check three questions.
- Is the vulnerable code reachable? Reachability analysis checks whether your code actually calls the affected function. If it does not, document that evidence.
- Is it known to be exploited? CISA recommends using its Known Exploited Vulnerabilities catalog as an input to prioritization. A listing there raises urgency sharply.
- What is the exposure? An internet facing service differs from an internal batch job.
Step 2: choose a path
| Path | When it fits |
|---|---|
| Upgrade | A fixed version exists and the change is tolerable |
| Replace | The package is abandoned or the fix will never come |
| Patch locally | You can safely carry a small change and document it |
| Mitigate | A config change or input check removes the exposure |
| Accept for now | None of the above is feasible yet, with a review date |
Step 3: write the exception properly
A good exception record has seven fields.
- The finding and affected component
- The asset or product it touches
- Why it cannot be fixed now
- The compensating control, such as a network rule or disabled feature
- The named owner
- Approver and approval date
- Expiry, usually 30 to 90 days
Short expiries keep the item visible. When it expires, the owner re-justifies it or closes it.
Step 4: watch for change
Set a recurring check for three triggers: a fixed version is released, the flaw appears in the exploited catalog, or exploit probability rises. The EPSS project publishes a daily probability estimate for each CVE, which makes the third trigger easy to automate.
What not to do
- Do not suppress in a config file with no comment.
- Do not let exceptions auto renew.
- Do not hide the item from reports. Leadership should see accepted risk.
- Do not treat a VEX statement or a reachability note as permanent. Code changes can make a function reachable later.
A worked example
Take a hypothetical service that depends on an older parsing library. A new advisory affects it, and the maintainer has not released a fix. The team walks through the steps.
They confirm the version is in the affected range. They check reachability: the vulnerable function parses a rarely used file type, and a search of the call graph shows the service never calls it. The library does not appear in the CISA Known Exploited Vulnerabilities catalog, and the EPSS probability is low. The service is internal, with no public route to the parser.
They choose a path. Upgrading is impossible since no fix exists. Replacing the library is a larger project, so they schedule it for the next quarter. In the meantime, they add an input check that rejects the affected file type, and they record an exception with a 45 day expiry. The record includes the reachability evidence, the compensating control, the owner, and a trigger: re-check if a fix is released or if the advisory appears in the exploited catalog.
At day 45 the owner reviews it. A new version has been released. The team upgrades, closes the exception, and removes the input check after testing.
Exception record template
| Field | Entry |
|---|---|
| Finding | Advisory identifier and component |
| Product | Where it runs |
| Reason no fix | No release, breaking change, or abandoned |
| Evidence | Reachability result and exposure notes |
| Compensating control | What reduces the risk now |
| Owner and approver | Names |
| Expiry | Date |
| Triggers | Fix released, exploited listing, exposure change |
Choosing between replace and patch
Replacement fits when the library is unmaintained, has a pattern of issues, or has a good alternative. Local patching fits when the change is small, the project is otherwise healthy, and you will contribute it back. Patching has a cost: you must carry the patch through every future update and document it, or the next upgrade will silently undo it.
Escalation rules
Set clear lines for who can approve what. For example, a team lead can approve a low risk exception up to 30 days, the security lead up to 90 days, and anything for an internet facing service with a known exploited flaw needs a director. Write these down in the exception process so nobody improvises under pressure.
Reporting accepted risk
Include accepted risk in regular reports with counts, ages, and owners. Visible risk gets managed. Hidden risk gets forgotten. A short monthly list of the oldest exceptions is often enough to keep the process honest.
Try it yourself
Click through it at your own pace, or open it full screen. Follow the questions that decide whether a finding is worth an exception at all.
Safeguard supports this with reachability analysis, policies and gates that can allow time limited exceptions, and compliance and evidence automation to keep the record. A free scan at gold.safeguard.sh/scan shows your current findings.
Quick check
How long should an exception last?
Short enough to stay visible, commonly 30 to 90 days. Longer needs a higher approver.
Is not reachable the same as safe?
No. It lowers risk today. Re-check when the code changes.
Can a gate fail forever on an unfixable finding?
It should not. Use a time limited exception with a compensating control so the gate keeps protecting against new issues.
Sources
Last reviewed: 19 October 2026.
