When no fixed version exists, you have four options: confirm whether the vulnerable code is reachable, mitigate around it, replace the package, or formally accept the risk with an owner and an expiry. Pick by exposure, not by the score alone, and record the decision.
Step 1: confirm it applies
Read the advisory. Which function, which configuration, which input triggers it? Many flaws need a specific feature enabled. If you do not use that path, the real exposure may be low. Reachability analysis can help, but verify by reading when stakes are high.
Step 2: look for a mitigation
Advisories often list workarounds: disable a feature, validate input before it reaches the library, restrict network exposure, or set a configuration flag. A mitigation that you document and test is a legitimate control while waiting.
Step 3: consider alternatives
- Switch to a maintained fork or another library. Cost rises with how deeply the package is woven in.
- Patch locally. Possible for open source, but you then own the patch. Track upstream.
- Remove the dependency. Sometimes the feature using it is not needed.
Step 4: accept with discipline
If the others fail, accept the risk formally. Record:
- The finding and the reason no action is taken
- The owner who approves it
- Compensating controls
- A review date, soon, such as thirty days
An exception without an expiry becomes permanent by neglect.
Watch for change
Subscribe to the package's advisory or issue thread. A fix may arrive quietly. Rescanning daily means you learn when a patched version appears.
What not to do
Do not hide the finding with a blanket ignore. Do not downgrade severity because it is inconvenient. Both make later audits and incidents harder.
Communicating the decision
Tell the people who depend on the decision. A short note to the product owner and security contact saying what the exposure is, what you did instead of patching and when you will look again avoids surprises. If a customer asks, you then have a dated, reasoned answer rather than silence.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a finding moves between statuses and where a reason is recorded.
Where Safeguard fits
Safeguard's dependency scanning marks whether a fix exists, and its reachability analysis helps with step one. Try the free scan.
Quick check
Can I just ignore it if the severity is low?
Low severity can justify a longer timeline, not silence. Record the decision.
Last reviewed: 19 October 2026.
