A dependency update policy a small team can keep is one page: security fixes get priority review, routine updates are batched on a schedule, every update needs a passing test run and a reviewer, and exceptions are written down with an owner and a date. Choose targets you already meet.
Why a policy helps with customers
Questionnaires ask how you keep third party code current. "We update regularly" says nothing. A short policy, plus a few merged pull requests as proof, answers it. The policy also protects the team from two bad habits: never updating, and merging every bump the moment it appears.
The structure
| Section | What to write |
|---|---|
| Scope | Which repositories and ecosystems the policy covers |
| Security updates | Triage within a stated period; prioritize by reachability and exposure |
| Routine updates | Batched weekly or monthly, one pull request per group |
| Review | One reviewer, passing tests, a glance at the changelog |
| Exceptions | Written reason, owner, expiry date |
| Records | Where the pull requests and decisions live |
Set targets you can actually meet
Do not copy a number from someone else. Look at what your team did over the last quarter and set the first target slightly better. A target you meet every time is stronger evidence than an ambitious one you miss. You can tighten it later and show the trend.
Keep two lanes. Security fixes should move quickly because a known flaw is a known risk. Routine updates can wait for a scheduled window.
Use a delay for routine bumps
Some teams add a short waiting period before adopting brand new releases, so that a malicious or broken version is more likely to be noticed and pulled before it reaches them. GitHub's Dependabot reference describes a cooldown option that delays version updates for a configurable number of days, and says it applies to version updates, not security updates. That split matches the two lanes above: wait on routine bumps, move promptly on security fixes. The trade-off is that you adopt useful features a little later.
Review what an update changes
For each pull request, look at the version jump, the changelog, any new install scripts, and any new transitive dependencies. A patch bump that adds ten packages deserves a second look. Your lockfile diff shows this clearly.
Handle exceptions in the open
Sometimes you cannot update: a breaking change, an abandoned package, a pinned platform. Record the reason, the mitigating control, an owner and an expiry date. Review expired exceptions each month. An exception log with dates is better evidence than a claim of perfect hygiene.
Test before merging
Automated tests are your safety net. If coverage is thin around a package, add a smoke test before updating it. Do not skip tests for a security fix; run the fastest meaningful subset.
What to show a reviewer
The policy, the update configuration file, a recent batch pull request, and the exception log. All dated.
Safeguard's dependency scanning and policies can flag vulnerable versions and enforce gates on pull requests, and autonomous remediation with fix PRs is available but off by default, with every category set to Manual. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Open the fix available now demo and see how a fixed version is surfaced to a developer. Watch what information accompanies the suggested change.
Click through it at your own pace, or open it full screen.
Quick check
Should we auto merge updates?
Only for low risk groups with strong tests, and only if your policy says so. Start with human review.
How often should routine updates run?
Weekly or monthly batches are common. Pick a rhythm the team will actually follow.
What if a fix is not available?
Record an exception with a mitigating control, an owner and a review date.
Sources
Last reviewed: 19 October 2026.
