An alert often has no automatic fix pull request for one of four reasons: no patched version exists yet, the fix needs a parent package to upgrade, the dependency is not in a manifest or lockfile the bot reads, or your rules filter the alert out. Each has a different next step, and each hides time inside your exposure window.
The four causes
GitHub's documentation for Dependabot security updates is a useful reference because it spells out the limits. Dependabot raises a pull request for an open alert that has an available patch. It checks that the upgrade to a fixed version does not break the dependency graph, then proposes the minimum version that includes the patch. If it cannot, it reports an error on the alert.
The same page notes that for indirect (transitive) dependencies in ecosystems other than npm, Dependabot cannot update the dependency if doing so would also require updating the parent. For npm it can raise a PR that updates an explicitly defined dependency to a secure version, even if that means updating the parent or removing a sub-dependency that is no longer needed. It also says security updates trigger just for dependencies specified in a manifest or lock file.
| Symptom | Likely cause | Next step |
|---|---|---|
| Alert says no patched version | Maintainer has not shipped a fix | Mitigate, pin, replace or accept with a review date |
| Error on the alert about the parent | Transitive fix blocked by parent range | Upgrade the parent, or override the resolved version |
| Alert present, no PR, no error | Auto-triage rule or security updates disabled | Check settings and rules |
| Dependency not found by the bot | Not in a manifest or lock file it reads | Add the lockfile or manifest to the scan path |
Steps to unblock
- Read the alert, not the PR list. The error message is on the alert.
- Find the dependency path. Use your package manager's tree or explain command to see which direct dependency pulls in the vulnerable one.
- Check whether a newer parent exists. If it does, upgrade the parent and test.
- If the parent is stuck, consider an override or resolution entry that forces the patched version, with a test and a comment explaining why. Remove it when the parent catches up.
- If no fixed version exists, record the decision: mitigate, replace or accept, with an owner and a review date.
Why this matters for the exposure window
Each of these causes is quiet. The alert exists, the clock is running, and nothing in the PR queue shows it. Teams that watch just open pull requests under-count exposure, because the stuck alerts have no PR to count.
A better habit is a weekly list of alerts older than a threshold you choose that have no linked pull request. Each row gets one of the next steps above and an owner.
Auto-triage rules can be the reason
Dependabot auto-triage rules let you dismiss or snooze alerts and choose which alerts get pull requests. GitHub's documentation says that if you prefer to customise which alerts get PRs you should leave security updates disabled and use an auto-triage rule. That is a legitimate setup, but a misconfigured rule produces exactly the symptom above. Review the rules when you wonder why a PR never arrived.
Try it yourself
Open the demo to see how a dependency inventory shows direct and indirect packages together, which is the first step in tracing a parent.
Click through it at your own pace, or open it full screen.
Safeguard's dependency scanning covers direct and transitive packages, and its fix pull requests (off by default) are meant for exactly these cases. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is a missing PR a sign the alert is a false positive?
No. It is a sign the bot could not or was told not to open one. Validity of the alert is a separate question.
Should I override a transitive version myself?
It is a valid short term fix if you test it and track it. Treat it as debt with a removal date.
Sources
Last reviewed: 19 October 2026.
