A never-auto-update list is safe when every entry has a reason, an owner and an expiry date, and when it lives in version controlled configuration rather than in someone's memory. Review the list on a schedule. Without those fields, exclusions quietly become permanent exposure.
Why exclusions are normal
Some packages cannot be bumped by a bot: a library with a known incompatibility, a vendor SDK tied to a contract, a package waiting on a major migration. Pretending otherwise leads to bot PRs that nobody can merge. Excluding them is reasonable. The risk is forgetting that you did.
Put it in config, not in comments
GitHub's documentation says that when you run Dependabot's ignore commands, it stores the preferences for the repository centrally. It adds that while this is a quick solution, for repositories with more than one contributor it is better to explicitly define the dependencies and versions to ignore in the configuration file, so everyone can see why a package is not being updated automatically. Follow that advice for any tool: keep exclusions in the repository where they are reviewed like code.
What each entry needs
| Field | Example content |
|---|---|
| Package and version range | Name, and which versions are excluded |
| Reason | "Major version needs a code migration" |
| Owner | A team, not a person who may leave |
| Created | The date you added it |
| Expires | The date you must decide again |
| Compensating control | What reduces risk meanwhile |
Most config formats allow comments or a description field. Use a short comment per rule, or keep a companion file such as a register that links to the rule.
Distinguish two kinds of exclusion
Version pinning for stability. You are staying on a version. Make sure security fixes for that line still flow, for example by allowing patch updates within the line while excluding the next major.
Ignoring a vulnerable package entirely. This is a risk acceptance, not a pin, and needs the stronger record: who accepted it, on what evidence, until when. See how to ignore a dependency advisory without hiding real risk. The tool's rule order also matters. See allow versus ignore rules in an update bot.
Review on a schedule
Once a month, list the entries expiring in the next month and ones already expired. For each, choose: renew with a new reason, remove, or turn it into a project to migrate. An expired entry still active is a finding in its own right. If an auditor asks how you manage exceptions, the register and the review log are the evidence.
Compensating controls
If you cannot update a vulnerable package, reduce the risk another way: restrict the code path, add input validation, put a rule in front of the service, or watch for exploitation. Say which in the entry. This keeps the exclusion honest, and reachability information can show whether the vulnerable code is even called.
When the owner leaves
Use team names. Review ownership when teams change, as a step in your reorganisation checklist. Orphaned entries are how pins survive for years.
Try it yourself
Open the demo and see how reachability shows whether vulnerable code is called. That evidence belongs next to every exclusion you record.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Is an ignore command in a pull request enough?
It works as a quick fix, but GitHub's documentation recommends defining exclusions in the configuration file so all contributors can see them.
How long should an exclusion last?
Pick a period that matches the risk and the planned migration. The important part is that every entry has an end date and a review.
Sources
Last reviewed: 19 October 2026.
