When no fix exists, the comment should say so in the first line, explain whether your code is exposed, offer a mitigation or an alternative, and say when the finding will be checked again. A comment that demands a fix that cannot be made teaches people to dismiss everything.
Why this case needs its own wording
Most comment templates assume a fix: bump to version X. When the advisory has no patched release, that line is empty. Developers see a failure they cannot resolve, and the easy move is to dismiss it with no reason.
An honest comment turns a dead end into a decision with options.
A template for the no fix case
No patched version available for example-lib 2.3.1
Advisory published, maintainers have not released a fix.
Exposure: your code calls parse() from api/upload.py, line 18, so this
finding is reachable. (Or: the vulnerable function is not called.)
Options:
1. Apply the mitigation in the advisory (input size limit).
2. Switch to a maintained alternative.
3. Accept the risk with a reason and an expiry date.
This finding will be rechecked on each scan. Dismissal expires in 30 days.
Four ideas carry the message: the fact that no fix exists, the exposure, the options, and the clock.
Exposure is the deciding detail
Without a fix, urgency depends on whether the vulnerable code is used. Reachability analysis answers that question by checking whether your code calls the affected function. If it does not, the comment can reasonably downgrade the item to informational and move on. If it does, the options above matter more.
Offer a path that is not "accept"
| Option | When it fits |
|---|---|
| Mitigation from the advisory | Maintainers published a workaround |
| Pin or vendor a patched fork | You have capacity to maintain it |
| Replace the dependency | An alternative exists and the swap is small |
| Time boxed acceptance | Exposure is low and the owner signs off |
Acceptance should always carry an owner and an expiry. Without them, it becomes permanent by neglect.
Tell developers what happens next
The most useful sentence in the comment is "this will be checked again". It tells the author the finding is not forgotten and that a future fix will surface automatically. Automated fix pull requests, where enabled, can open when a patched release appears, so the author is not left to watch the advisory.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the findings that have a fix with the ones that do not, and think about how each comment should read.
Safeguard provides reachability analysis for dependency findings, which helps separate exposed no fix cases from unreachable ones. A free scan will show which of your findings have fixes.
Quick check
Should a no fix finding block the merge?
Usually not on its own, unless it is reachable and severe and your policy says so. Blocking on something the author cannot fix stalls work without reducing risk.
How long should an acceptance last?
Pick a short default, such as 30 days, and renew it only with a fresh look at exposure. The exact number is your policy choice.
Last reviewed: 19 October 2026.
