Size it from your own history. Measure the update and fix work that actually arrived over a quarter, set a standing slot slightly above that, and revisit it every quarter. No universal percentage is right for every product, so be wary of any rule of thumb presented as one.
Why a fixed percentage fails
Products differ in how many dependencies they carry, how fast those ecosystems move, how strong the tests are, and how many supported versions must be patched. A team with thin tests pays more per update. A product with a long support period carries more branches. A single number ignores all of this.
Measure for a quarter
Track these simply, in the ticket system you already use.
| Measure | How to get it |
|---|---|
| Update pull requests opened and merged | Count from the repository |
| Hours spent on updates and security fixes | Tag the tickets |
| Interruptions from exploited vulnerabilities | Count and note the cost |
| Time lost to broken updates | Tag the incidents |
After one quarter you have a baseline. Add the planned big items: major upgrades with deadlines, such as the end of security support for a framework, and any support promises you have made.
Set the allocation
- Start with the baseline of routine work as a standing slot each sprint.
- Add named roadmap items for the major upgrades, each with an estimate.
- Keep a small reserve for urgent work. CISA describes its Known Exploited Vulnerabilities catalog as an input to prioritization, so exploited findings will sometimes interrupt planned work.
- Review the numbers each quarter and adjust.
Reduce the demand, not just fund it
Capacity is one lever. The other is the volume of work. Fewer dependencies mean fewer updates; the OpenSSF guide to evaluating open source software begins by asking whether an existing component can already do the job. Good tests make updates cheap. Automation of routine patch updates, with a human reviewing minor ones, frees time for work that needs judgment.
Show the tradeoff
When leadership asks why a feature slipped, show the maintenance numbers and the commitments they protect, such as a published support window or a patching promise. A visible trend line is easier to defend than a general claim.
Warning signs
If the oldest open update keeps getting older, or exceptions pile up past their expiry, the allocation is too small or the tests too weak to trust.
Quick check
Is there a standard percentage to reserve?
Not one we can support with a source. Measure your own work and set it from that.
Who owns the number?
The product manager and engineering lead together, reviewed quarterly.
Safeguard's continuous dependency scanning and its policies and gates give you the counts and ages to base this on, and the free scan is at gold.safeguard.sh/scan.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- OpenSSF Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
