A dependency update policy should say who owns updates, how often routine updates happen, which vulnerabilities take a faster path, how exceptions are recorded, and how you check the policy is working. One page is enough. The goal is predictable small updates instead of rare, risky ones.
Why write it down
Without a policy, updates happen when someone has spare time or when something breaks. Both are bad moments. A written cadence turns updates into routine work with a known cost, which is what a product manager needs to plan around.
Sections to include
1. Scope. Which repositories and package ecosystems the policy covers, including container base images and build tools.
2. Owners. One named team per repository. Ownership by "everyone" means no one.
3. Routine cadence. For example, a regular slot each sprint for reviewing and merging update pull requests. Pick a rhythm the team can sustain.
4. Fast path. A faster track for vulnerabilities with evidence of exploitation. CISA describes its Known Exploited Vulnerabilities catalog as an input for prioritization, and FIRST describes EPSS as an estimate of exploitation probability over the next 30 days, meant to complement other signals. Use them to decide who jumps the queue.
5. Version rules. Under Semantic Versioning, patch and minor releases are meant to be backward compatible and major releases are not. A common rule is to auto merge patch updates after tests pass, review minor updates, and plan major ones as roadmap items.
6. Gates. What blocks a release, such as a known exploited vulnerability with no exception.
7. Exceptions. Who can approve a deferral, for how long, and where it is recorded.
8. Measures. Age of the oldest outstanding update and number of open exceptions are simple, honest measures.
A table to adapt
| Update type | Default handling | Escalation |
|---|---|---|
| Patch, tests pass | Merge in the routine slot | None |
| Minor | Review in the routine slot | Owner decides |
| Major | Roadmap item | Product manager and tech lead |
| Exploited vulnerability | Same week fix or mitigation | Security lead informed |
Keep it alive
Review the policy twice a year. If exceptions pile up, the cadence is wrong or the tests are too weak to trust, and that is a roadmap item.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory against an existing component raises an alert without a new scan being run by hand. That is the trigger for your fast path.
Quick check
Should patch updates merge automatically?
Often yes, after tests and a scan pass. Decide per repository based on test strength.
How long can an exception last?
Set an expiry, usually short, and require a fresh approval to renew it.
Safeguard's policies, gates, and continuous scanning can enforce rules like these, and you can try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
