If an advisory lists no patched version, look for a documented workaround, reduce exposure around the affected feature, decide whether to replace the package, and set a date to recheck. Do not wait silently, and do not dismiss the finding without a recorded reason.
Where to look first
GitHub describes the contents of an advisory as the description, severity, affected package, ecosystem, affected versions and patched versions, impact, and optional extras such as references, workarounds and credits. Workarounds are optional, so one may or may not be present. If the patched versions field is empty, the maintainer has not published a fixed release at the time of the record.
Check three places for movement: the advisory itself, which can be updated, the project's issue tracker or release notes, and any announce list the project runs.
Your options
| Option | Good when | Watch out for |
|---|---|---|
| Apply the documented workaround | The advisory describes one | It may reduce functionality, record that |
| Disable or isolate the affected feature | You do not need it | Confirm it is really off in production |
| Restrict who can reach it | It sits behind a network or auth boundary | Boundaries change, so review |
| Replace the package | Alternatives exist and risk is high | Migration cost and new risk |
| Fork and patch | You have the skills and the licence allows | You now own the fix |
| Accept for now | Low exposure and a review date is set | Needs a named approver |
A decision path
- Does the advisory describe a workaround? If yes, apply it and test.
- Is the affected feature used in your product? If not, remove or disable it and note how you verified.
- Is the vulnerable code path reachable from untrusted input? If not, document that evidence.
- Is the package maintained? Look at recent commits and releases. If it appears abandoned, plan a replacement.
- If you must keep running it, add monitoring for exploitation attempts and set a recheck date, such as two weeks.
Our guide on whether a library will backport security fixes is useful when a fix exists on a newer line but not yours.
Be careful with the word "fixed"
A commit that fixes the bug is not the same as a release you can install. Until a version exists, scanners will keep flagging the package. Do not edit the lockfile to a git commit unless you understand what else changed, and who published it.
Communicate the exception
If a customer or auditor can see this finding, write a brief exception: what the issue is, what you did, who approved, when you will review. That is far better than an unexplained open item.
Where Safeguard fits
Safeguard's reachability analysis helps show whether the affected code is called, and its policies and gates let you set how long such an exception may stand. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Note which findings the demo marks as unreachable and how that changes their priority.
Quick check
Should I block the build until a fix exists?
Only if the risk justifies it. Many teams allow a time limited exception with a named approver and a review date.
Is a workaround as good as a patch?
No. It is a stopgap that usually limits behaviour. Plan to move to a patched version when one appears.
Sources
Last reviewed: 19 October 2026.
