How Much Engineering Time to Budget for Dependency Upgrades Each Quarter

There is no universal percentage. Size the budget from your own history: how far behind your key dependencies are, how many fixable advisories land each quarter, which runtimes and frameworks reach end of support in the next two quarters, and what an upgrade has actually cost your teams. Turn that into a standing allocation per team, reserve a slice for emergencies, and report it upward as risk retired rather than tickets closed.

This post is for the engineering leader whose dependency backlog keeps losing the planning argument. It gives you a sizing method you can run on a spreadsheet this week, a worked example with illustrative numbers, planning rules that stop the allocation being raided, and a one page board report.

Key takeaways

• Treat dependency upkeep as planned capacity, the same way you plan on-call. NIST SP 800-40 Rev. 4 frames patching as preventive maintenance and "a standard cost of doing business".
• Size the work from five signals you already have or can get: version lag, fixable advisories, exploitation signals (CISA KEV and FIRST EPSS), end-of-support dates, and the measured cost of past upgrades.
• Split the budget into three buckets: routine upkeep, scheduled major or runtime moves, and an emergency reserve. Each is sized differently.
• Protect the allocation with a written planning rule, a named owner per team, and a rule for what happens to unspent reserve.
• Report to the board in risk terms: supported runtimes, exploited vulnerabilities open past target, end-of-support exposure ahead, and allocation used versus planned.
• Cut the cost per upgrade with grouping, test coverage on the upgrade path, and automated pull requests that still go through review.
• In Safeguard: SBOM generation and SCA (GA), vulnerability management with EPSS and KEV signals (GA), reachability analysis (GA), autonomous remediation with single and bulk fix pull requests (GA, ships switched off, every category Manual), policies and gates (GA), the CLI (GA) and dashboards (GA). None of them sets the allocation or makes the roadmap trade-off.

The situation

Planning starts in two weeks. Product has a list of commitments that already exceeds headcount. Somewhere in the backlog sit forty tickets with titles like "bump framework to next major", "move service off end-of-life runtime" and "upgrade logging library". Each quarter they get pushed, because each one on its own looks small, deferrable and invisible to customers.

Then a critical advisory lands for a library three major versions behind. The fix exists only on the newest major line, so the "patch" is a three-major migration done under pressure by whoever is on call. Two feature teams stop for a week, and the next planning cycle repeats the pattern.

You need a number for dependency upkeep that you can defend against roadmap work, that the CEO understands, and that holds up when someone asks in month two why a team is not shipping features. A bad week looks like this: an exploited vulnerability in a dependency you cannot upgrade quickly, a sales team fielding customer security questionnaires about it, and no data to show that the gap was a choice rather than neglect.

The rules and standards behind the number

None of the sources below tells a private SaaS company how many hours to spend. They do tell you what a reasonable program looks like, which is what you need when the allocation is challenged. This is engineering guidance, not legal or regulatory advice; if a contract or regulator imposes specific timelines on you, those govern.

NIST SP 800-40 Rev. 4: patching is preventive maintenance

NIST SP 800-40 Rev. 4, the "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology" (April 2022), is the clearest statement of the principle you need in planning. Its executive summary says patching should be considered "a standard cost of doing business" and compares it to preventive maintenance on a vehicle fleet that avoids costly breakdowns. It also names the exact tension you face: business owners may see patching as a drag on productivity, and NIST asks leadership to reconsider that priority given current risk.

Several sections map directly onto a quarterly budget:

• Section 3.1, Reduce Patching-Related Disruptions, recommends deploying software in ways that make patching less disruptive, including existing toolchains that build applications with updated components and test them before they reach production. That is the case for investing in test coverage on the upgrade path.
• Section 3.2, Inventory Your Software and Assets, says organizations should maintain up-to-date software inventories, relying on automation to keep them close to complete. You cannot size upgrade work without knowing what you run.
• Section 3.3 defines risk response scenarios, and Section 3.5 asks for a maintenance plan for each: routine patching, emergency patching, emergency mitigation and unpatchable assets. Your three budget buckets come from this split.
• Section 3.5.1 recommends giving flexibility on how soon routine patches are installed, but forcing installation once a grace period ends. That is a planning rule, not just an operations rule.
• Section 3.5.5 says exceptions to maintenance plans should be tracked and reviewed regularly.
• Section 3.6 warns that overly simple metrics, such as the percentage of vulnerabilities patched across the organization, are not actionable, and that different audiences (it names the CEO and Board of Directors) need different metrics. Its Table 1 is a notional matrix of patching performance by asset importance and vulnerability importance.

NIST SP 800-218 (SSDF) PW.4 and RV.2

The Secure Software Development Framework, NIST SP 800-218 version 1.1 (February 2022), is the standard most enterprise customers cite in security questionnaires. Two practices matter here.

PW.4 asks you to reuse existing, well-secured software, and its stated purpose includes lowering the cost of software development. Task PW.4.1 covers acquiring and maintaining well-secured third-party components; one of its notional examples is to implement processes to update deployed software components to newer versions. Task PW.4.4 asks you to verify that third-party components comply with your requirements throughout their life cycles. Its examples include regularly checking for publicly known vulnerabilities, building automatic detection of known vulnerabilities into the toolchain, ensuring each component is still actively maintained and has not reached end of life, and determining a plan of action for each component that is no longer maintained.

RV.2 covers assessing, prioritizing and remediating vulnerabilities. RV.2.1 asks you to analyze each vulnerability for enough risk information to plan its remediation, and suggests risk calculations based on exploitability and impact. RV.2.2 asks you to plan and implement risk responses, including a risk-based decision on whether to remediate or accept.

If a customer asks how you meet PW.4.4 and RV.2, a standing upgrade allocation with a written sizing method is a far better answer than "we patch when something comes up".

CISA KEV and BOD 26-04: why exploitation status drives the reserve

CISA's Known Exploited Vulnerabilities catalog is the authoritative list of vulnerabilities exploited in the wild, and CISA's own catalog page says organizations should use it as an input to their vulnerability management prioritization framework.

For federal agencies, Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk" (10 June 2026), now sets remediation timelines. It revoked BOD 22-01, which had set fixed KEV deadlines. BOD 26-04 decides urgency from four factors: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation is automatable, and whether the technical impact gives partial or total control. Its Table 1 sets the timelines; the most urgent combination requires remediation within three days plus forensic triage. At the other end, some combinations are marked "fix on system upgrade", which the directive defines as remediating the next time the asset receives a scheduled major upgrade or rebuild.

BOD 26-04 binds federal civilian agencies, not a commercial SaaS company. It is still the best public model of the idea this post rests on. Low-risk findings can wait for the next scheduled upgrade, but only if scheduled upgrades actually happen. If your organization never schedules them, "fix on system upgrade" quietly becomes "never". The directive states the logic plainly: act quickly on high-risk vulnerabilities and defer action on low-risk ones.

FIRST EPSS: probability, not severity

FIRST's Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the wild in the next 30 days. FIRST publishes a score between 0 and 1, with percentiles, every day for every CVE, freely available. EPSS is useful for budgeting because it lets you estimate how much of your fixable advisory volume is likely to turn urgent, which is what the emergency reserve has to absorb.

Semantic Versioning, project health and end-of-support dates

Three more public sources make the size of upgrade work predictable.

• Semantic Versioning 2.0.0 says the major version changes for incompatible API changes, the minor for backward compatible functionality and the patch for backward compatible bug fixes. It also says major version zero is for initial development and "anything MAY change". In practice, a version jump on a project that follows SemVer tells you roughly how much work to expect, and a project on 0.x tells you to expect surprises.
• OpenSSF Scorecard runs automated checks on open source projects. Its "Maintained" check gives the highest score to a project with at least one commit per week over the previous 90 days and the lowest to an archived project. Its "Dependency-Update-Tool" check looks for an automated update tool. Both are signals about projects you depend on.
• Runtime and framework lifecycles are published. The Node.js project says production applications should use only Active LTS or Maintenance LTS releases, that LTS typically means critical bugs are fixed for a total of 30 months, and that starting with Node.js 27 the release cycle becomes annual. The Python developer guide says a release gets bug fixes for two years (18 months for versions before 3.13), then security fixes only, and support ends five years after release. These dates are known years in advance, which makes them the easiest part of the budget to plan.

Why unplanned dependency work costs more than planned work

Engineering leaders know this intuitively. The planning argument needs it spelled out, because the person across the table sees only the visible cost of the planned version.

Skipped versions compound. An upgrade from one minor version to the next is usually small. Skip four quarters and the next forced upgrade may cross two or three major versions, each with its own breaking changes. SemVer tells you exactly where those breaks live: every major increment is, by definition, an incompatible change. The work does not add up linearly; you also lose the option of taking the steps one at a time.

Fixes land on new lines first. Maintainers fix vulnerabilities on supported release lines. If you are on a line that is past end of support, there may be no patch for your version at all, and the "security patch" becomes a migration. NIST SP 800-40 Rev. 4 lists software at end of life among the reasons a patch will never be released.

Interrupts cost more than the task. An emergency upgrade pulls the engineer who knows the service best off planned work mid-sprint. The lost context, the slipped release and the replanning rarely show in a tracker, which is why this cost loses the planning argument.

Emergency work skips the safety steps. NIST's routine plan uses phased rollouts with canary assets; its emergency plan compresses the canary phase to minutes or hours. Compressed testing means more rollbacks and reverted upgrades.

The planned version of the work is smaller, safer and schedulable. You do not need an industry statistic to make that case; you need your own last four quarters of interrupts.

Which signals size the work

Five signals, each available without buying anything, are enough to size a quarterly budget. The table shows where each comes from and what it predicts.

Two signals refine the estimate: how often key libraries ship breaking majors, and project health. An archived or barely maintained project (OpenSSF Scorecard's "Maintained" check is one public signal) may need replacement, which is a project, not upkeep.

Version lag, measured the useful way

Total packages behind is a noisy number. A service with three hundred transitive packages will always have dozens behind by a patch version, and that tells you nothing. Measure lag on the dependencies that matter:

1. List the direct dependencies of each service.
2. Mark the ones that carry real risk or real migration cost: web framework, ORM or database driver, auth and crypto libraries, serialization, HTTP clients, the runtime itself, and your build toolchain.
3. For each, record the version in use, the latest version, and the number of major versions behind.
4. Record whether the version you run is still on a supported line.

That short list predicts most of the cost.

Advisories, split by what you can do about them

Not every advisory is upgrade work. Split them:

• Fixed version exists, small bump. Routine upkeep.
• Fixed version exists, but only on a newer major. This is a major upgrade disguised as a patch. Count it with major upgrades.
• No fix exists yet. Needs mitigation or a different response, not upgrade time. NIST's emergency mitigation and unpatchable scenarios cover this.
• Vulnerable code is not reached by your application. Still worth fixing on schedule, but rarely an emergency. Reachability analysis is how you tell, and the reachability capacity post covers how it changes a fix plan.

End-of-support dates, on a calendar

Pull the end-of-support dates for every runtime, framework and major library in production into one calendar with a six quarter horizon. Anything that loses support inside two quarters needs a slot in this plan. Anything inside four quarters needs a named owner and an estimate. This is the most predictable part of the budget and the one most often missed, because nobody owns the calendar.

Step by step: build the quarterly upgrade budget

This works with a spreadsheet, a scanner you already have and your issue tracker.

1. Pick the unit. Budget per team, not per service and not company-wide. Teams own the code and carry the interrupts.
2. Measure your cost per upgrade from history. Pull the last four quarters of dependency upgrade tickets and pull requests. Classify each as a patch or minor bump, a major upgrade, or a runtime or framework move. Record engineer-days for each. Use medians, not averages, since one disastrous migration will distort an average.
3. Count the interrupts. From the same period, list every unplanned upgrade: security-driven, breakage-driven or end-of-support surprise. Record engineer-days and whether it displaced planned work.
4. Inventory the queue. Using the version lag method above, list queued major upgrades and runtime moves per team, with estimates from your medians.
5. Forecast advisory volume. Count fixable advisories per quarter over the last four quarters. Use the median as the forecast. Note what share were KEV listed or had a high EPSS score; that share sizes the reserve.
6. Lay out end-of-support dates. Anything inside two quarters is planned work in this quarter or the next.
7. Size the three buckets. Routine upkeep is forecast volume times median cost. Scheduled moves are the queue items you commit to this quarter. The emergency reserve is your historical interrupt cost, adjusted for what the queue removes.
8. Convert to a share of capacity. Divide by the team's available engineer-days after on-call, holidays and other fixed commitments.
9. Write the rule. Record the allocation, the owner, what counts against it, and what happens to unspent reserve.
10. Review at the end of the quarter. Compare planned against actual, update medians, and adjust the next allocation.

A template you can copy

Worked example: one team, one quarter (illustrative)

The numbers below are invented and round. They show the arithmetic, not a benchmark. Replace every figure with your own.

A product team of six engineers has about 300 available engineer-days this quarter after on-call, holidays and fixed commitments. From its last four quarters:

• Median cost of a patch or minor bump, grouped weekly: half a day per weekly batch.
• Median cost of a security-driven bump with a fixed version available: half a day, but roughly one in ten broke something and took about three days.
• Median cost of a major upgrade of a key library: five days.
• Median cost of moving one service to a new runtime version: four days.
• Unplanned upgrade work last year: about 40 engineer-days per quarter on average, most of it displacing planned work.

This quarter's queue and forecast:

• Twelve weekly routine batches.
• About 20 fixable advisories expected, the median of the last four quarters.
• Three major upgrades queued for key libraries, one of them blocking a security fix.
• Four services on a runtime version that loses support in two quarters; the team plans to move two this quarter and two next.

Fifty-five of three hundred is a little over 18 percent of capacity. In this illustration the team spent about 40 days a quarter on unplanned upgrades last year, mostly as interrupts, with no queue reduction to show for it. The plan spends more in total, but most of it is scheduled, the queue shrinks, and the reserve should shrink in later quarters as lag falls. If it does not shrink, that is a finding worth bringing to the next planning cycle.

Your answer may be 8 percent or 25 percent; a fast-moving framework and a heavy end-of-support calendar push it up. The reserve is the line that gets challenged, so show the interrupt history behind it.

How to protect the allocation in quarterly planning

A number that is agreed in planning and raided in week three has failed. These rules keep it.

1. Put it in the plan as a line item, per team. Not "tech debt time", not "20 percent time". A named allocation for dependency upkeep with the three buckets visible.
2. Name an owner per team. One engineer per team owns the upgrade queue for the quarter. Rotate the role so knowledge spreads.
3. Commit the scheduled moves by name. "Move two services to the supported runtime" is protectable. "Work on upgrades" is not.
4. Decide in advance what the reserve does when it is unused. Two workable rules: unused reserve flows to the next items in the upgrade queue, or it flows back to the roadmap in the last two weeks of the quarter. Either is fine. Not deciding means it disappears into feature work by week four.
5. Make borrowing visible. If a product leader wants to borrow from the allocation, it is a decision recorded with the risk it carries, including which upgrade slips and which end-of-support date it moves closer to. NIST asks that exceptions to maintenance plans be tracked; treat a borrowed allocation as one.
6. Use a grace period with a hard end. Following NIST's routine patching guidance, set a window for routine upgrades and a point at which they are no longer optional. For example, patch and minor bumps for key dependencies merge within a set number of weeks; supported-line moves complete before end of support.
7. Tie it to release planning. Schedule major upgrades early in a release cycle, not in the week before a launch.
8. Review planned versus actual every quarter. Bring the comparison to planning. A team that consistently overruns its reserve needs either more allocation or a look at why upgrades are expensive.

Answers to the questions you will get in planning

What to report to the CEO and board each quarter

Boards do not want ticket counts. NIST SP 800-40 Rev. 4 Section 3.6 makes the same point: simple counts are not actionable, and executives need metrics framed by asset importance and vulnerability importance. Report the allocation as risk retired, and keep it to one page.

A one page quarterly report

Every number in that table is invented for illustration. The point is the shape: each line answers "is our exposure going up or down, and did we spend what we said we would".

Lead with the change in exposure, then the spend, and keep the same measures for four quarters so the board sees a trend. Say which risks you chose to carry and why; a deliberate deferral of low-risk findings to the next scheduled upgrade is defensible, an untracked backlog is not.

If your security leader already reports to the board, merge your lines into theirs; the security debt versus technical debt post helps agree which items count where.

How to cut the cost per upgrade

The allocation is a function of volume times cost per upgrade. You control the second term more than the first.

1. Group routine bumps. One weekly or fortnightly batch of patch and minor bumps per service, reviewed together, costs less than twenty separate pull requests. Group by risk: low-risk bumps together, key libraries alone.
2. Test the upgrade path, not just the features. Most upgrade cost is uncertainty. Contract tests at your boundaries, a smoke suite that exercises the framework integration and a staging environment that resembles production turn "might break" into "did or did not break" in minutes. NIST's Section 3.1 points at exactly this: toolchains that build with updated components and test them before release.
3. Use automated pull requests, and still review them. An automated pull request removes the mechanical work: editing manifests, updating lockfiles, writing the description. It does not remove the need for tests and review. The unmerged pull requests post covers why they pile up and how to keep them moving.
4. Pin and lock deliberately. Lockfiles make builds reproducible and make upgrades explicit changes rather than surprises. OpenSSF Scorecard's "Pinned-Dependencies" check is one public reference for why.
5. Take majors one at a time and early. Upgrading one major behind, soon after release, is cheaper than jumping several majors later, because each migration guide assumes you are coming from the previous major.
6. Prefer well-maintained dependencies. SSDF PW.4.1 and NIST SP 800-40 Section 3.1 both point at choosing software that will need fewer fixes. Before adding a dependency, check maintenance signals and release habits.
7. Remove what you do not use. An unused dependency still costs upgrade time and carries advisories.
8. Record the cost of every upgrade. Without it you cannot update medians, and the next planning argument starts from opinion again.

How Safeguard does this

The method above works with any tooling. Safeguard gathers the inputs continuously, ranks them, opens routine fix pull requests and shows the trend. The steps follow Safeguard's offering documentation and docs.safeguard.sh; where the docs show no screen or command, only the outcome is described.

1. Build the inventory with SBOM generation and SCA (GA). Safeguard generates SBOMs in SPDX and CycloneDX and runs software composition analysis across the full transitive dependency tree, including container layers. Each project's Dependencies tab has a tree view and a table view listing component name and version, license, vulnerability count and last updated date, a direct input to the version lag measure. From a developer machine or a CI job, the Safeguard CLI (GA) builds an SBOM and matches it against vulnerability databases. The docs show the install and a directory scan:

   curl -fsSL https://cli.safeguard.sh/install | bash
   safeguard scan --dir .
   

   Results are written as JSON files under the output directory (default ./output). The docs note that safeguard scan does not fail on findings; it exits 0 when the scan ran. These commands are as the docs show them; they were not run for this post.

2. Keep it current with continuous scanning. The vulnerabilities docs say Safeguard rescans all projects daily, and re-evaluates projects when new CVEs are published. Your advisory volume forecast then comes from a continuous record instead of a quarterly scramble.

3. Separate urgent from routine with vulnerability management (GA) and reachability analysis (GA). Vulnerabilities are grouped as Critical, High, Medium, Low and Exploitable, where Exploitable means known exploitation in the wild. Each finding shows the CVE, CVSS score, EPSS score, whether it is exploitable, the affected component, the fixed version and whether the vulnerable code path is reachable. Prioritization weighs exploitability (EPSS and CISA KEV), reachability (call path, runtime context and configuration) and business context. You can filter by EPSS range, exploitable status, fix availability and reachability status. In budget terms: fixable, exploited, reached findings go to the reserve; fixable unreached ones go to routine upkeep; unfixed ones go to mitigation planning.

4. See what an upgrade will cost before you schedule it. From a vulnerability, View Fix shows upgrade options with breaking change warnings. The remediation docs classify breaking change risk as Safe, Minor, Major or Critical. That classification is a useful first sort for the routine and scheduled buckets: Safe and Minor fixes usually belong in routine batches, Major and Critical in scheduled work with an owner.

5. Record the risks you choose to carry. The vulnerabilities docs provide Accept Risk with an expiration date and business justification, submitted for approval, and Mark False Positive with a justification. Expiring acceptances are how a "fix on the next scheduled upgrade" decision stays a decision rather than becoming permanent.

6. Turn routine fixes into pull requests with autonomous remediation (GA, ships switched off). AI Remediate, powered by Safeguard's Griffin models, analyzes the vulnerability and the codebase, picks an upgrade path, assesses breaking changes, opens a pull request and runs validation. The docs describe three modes: a single vulnerability, bulk remediation of selected vulnerabilities with compatible fixes batched into one pull request per repository, and page-level remediation from the Vulnerabilities page. Generated pull requests carry the CVE reference, a description, a summary of changes, breaking change warnings and test results if configured. Settings documented under AI Remediate include whether to require approval before pull requests, running tests before creating them, and a breaking change policy. Autonomous remediation ships switched off, with every category set to Manual, so nothing changes until your team turns it on and chooses how much runs without a human. Bulk pull requests are the mechanism that makes the "group routine bumps" rule cheap.

7. Hold the line in CI with policies and gates (GA). Policies and gates are evaluated in the platform, not by the CLI. Gate actions are Block, Warn and Notify, and approvals run through exceptions. For a budget, a Warn gate on new findings keeps routine work visible without stopping releases, while a Block gate can be reserved for the conditions your plan says are never acceptable.

8. Report the trend with dashboards (GA). The dashboard docs describe vulnerability trends over time with mean time to remediation, a fix rate view showing fixes per week and AI Remediate versus manual fixes, time to fix by severity, a Top Risks list including aging vulnerabilities and actively exploited CVEs, and a component health view that tracks outdated components over time. The offering documentation describes an executive risk dashboard across the whole platform, with every number clickable through to the underlying results. Dashboards export to PDF, and the docs describe scheduled weekly or monthly email reports. Those views cover most of the one page board report above; the allocation used versus planned line still comes from your planning tool.

Where each Safeguard capability fits the budget

What Safeguard does not do

• It does not set your allocation. Safeguard shows inventory, findings, fix availability and trends. The share of capacity, the size of the reserve and what happens to unused time are engineering leadership decisions.
• It does not decide roadmap trade-offs. When a launch competes with a runtime move, someone with authority over both makes that call. Safeguard can show the risk being carried; it cannot weigh it against revenue.
• It does not write your tests. Fix pull requests can run your existing tests and report results. If coverage on the upgrade path is thin, a passing run means little. Building that coverage is your team's work.
• It does not catch every breaking change. Breaking change classification is an assessment, not a guarantee. Behavioural changes that do not show up as API changes, and differences that only appear under production load, can still get through. Review and staged rollout remain necessary.
• It does not give you an hours-saved figure. Nothing here claims a number of engineer-days saved. Measure your own cost per upgrade before and after, as described above.
• It does not merge or deploy for you. Pull requests go through your review, CI and deployment process.
• It does not fix software you do not build. Vendor appliances, hosted services and operating system packages outside your images still depend on their vendors' release schedules.

Common mistakes

• Budgeting a flat percentage without data. "Twenty percent for tech debt" gets negotiated away because nobody can defend it. A number built from your own interrupt history and queue holds up.
• Counting all packages behind. It produces a huge, meaningless number. Measure major-version lag on key dependencies instead.
• Treating every advisory as urgent. Without exploitation and reachability signals, the reserve absorbs everything and routine upkeep never happens. Use KEV, EPSS and reachability to split the work.
• No reserve. Without one, every urgent fix displaces roadmap work and the plan looks broken by week four.
• A reserve with no rule. Unspent reserve that silently disappears teaches everyone the allocation is optional.
• Ignoring end-of-support dates until the last quarter. They are published years ahead. Missing them is a planning failure, not bad luck.
• Merging automated pull requests without tests. Automation removes the mechanical work, not the risk. An untested upgrade that breaks production costs the program its credibility.

FAQ

How much engineering time should we budget for dependency upgrades?

Size it from your own data rather than a rule of thumb. Add routine upkeep (forecast advisory and bump volume times your median cost), scheduled major and runtime moves, and an emergency reserve sized from your interrupt history. In the illustrative example above that came to a little over 18 percent of one team's capacity; your figure will differ.

Is there an industry standard percentage for dependency maintenance?

Not in the primary sources. NIST SP 800-40 Rev. 4 treats patching as a normal cost of running technology and recommends planned maintenance for each scenario, but it does not set a percentage. Treat any published percentage as a starting point to check against your own history.

Should dependency upgrades come out of the tech debt budget?

Track them separately. Upgrade work has external deadlines (end-of-support dates, exploited vulnerabilities) that ordinary technical debt does not, and lumping them together lets the deadline-driven work lose to refactoring preferences.

How do I convince product leadership to protect upgrade time?

Show your last four quarters of unplanned upgrade work and what it displaced, then show the planned alternative and how it shrinks the queue. Agree up front on what happens to an unused reserve so nobody sees the allocation as idle time.

What metrics should I report to the board about dependency risk?

Services on supported runtimes, exploited vulnerabilities in reached code open past your target, end-of-support exposure in the next two quarters with owners, median major-version lag on key dependencies, and allocation used versus planned. Avoid percentage of all vulnerabilities patched.

Do EPSS and the CISA KEV catalog replace CVSS for prioritization?

They answer different questions. CVSS describes severity, EPSS estimates the probability of exploitation in the next 30 days, and KEV records exploitation already seen in the wild. Use all three, together with whether your code reaches the vulnerable path.

Can automated dependency pull requests replace a quarterly upgrade budget?

No. They reduce the mechanical cost of routine bumps, which lowers the routine bucket. Major upgrades, runtime moves, test fixes after breaking changes and the review itself still need planned time.

Does BOD 26-04 apply to private SaaS companies?

It binds federal civilian agencies. Its risk factors (exposure, KEV status, automatable exploitation and technical impact) and its "fix on system upgrade" category are still a useful public model for deciding what goes in the emergency reserve and what waits for scheduled upgrades. If you sell to federal agencies, check your contract terms for what they require of you.

What should we do with dependencies that are no longer maintained?

SSDF PW.4.4 suggests determining a plan of action for each component that is no longer maintained. Usually that means replacing it, vendoring and maintaining it yourself, or isolating it. Each option is a project, so give it a slot in the scheduled bucket rather than the routine one.

Before you plan around fixes you cannot schedule

A standing upgrade allocation covers the work you can schedule: routine bumps, major moves and runtime changes. It cannot shorten the time a maintainer takes to ship a fix, or help when the fix lands only on a line you are not yet ready to move to, which is what the next section covers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. After install, running safeguard opens the interactive terminal; the user asks it to "fix the lodash CVE in this repo", and it reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan. This is the routine bucket in miniature: one fixable advisory, one small bump, tests run before anything is proposed.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. Before planning, the same connection lets you ask your Safeguard data plain questions, such as which findings are fixable and exploited, while you control what the assistant can touch.

Click through it at your own pace, or open it full screen.

For the week when the reserve is not enough, the surge capacity plan for a zero-day week covers how to staff it.

Quick check

To try the inventory and fix flow on your own code, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh.

Sources

• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology (publication page)
• NIST SP 800-40 Rev. 4 (PDF)
• NIST SP 800-218, Secure Software Development Framework version 1.1 (publication page)
• NIST SP 800-218 (PDF)
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04, Prioritizing Security Updates Based on Risk
• FIRST Exploit Prediction Scoring System
• Semantic Versioning 2.0.0
• OpenSSF Scorecard
• OpenSSF Scorecard check documentation
• Node.js releases
• Python Developer's Guide: status of Python versions
• Safeguard docs: Explore SBOM
• Safeguard docs: Vulnerabilities
• Safeguard docs: AI Remediate
• Safeguard docs: Dashboard
• Safeguard docs: CLI
• Safeguard docs: CLI usage

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.