If you have inherited a codebase with dependencies that have not been updated in a year or more, use the first 30 days for visibility, the next 30 for urgent fixes and cheap updates, and the last 30 for major upgrades and a routine. Do not promise a clean slate in 90 days. Promise a visible trend.
Days 1 to 30: see it clearly
- Inventory: list direct and transitive dependencies with versions, plus runtimes and base images.
- Support dates: record end of life dates for each runtime. Python and Node.js publish status for each release.
- Owners: name a person for each service, or note that none exists.
- Known exploited check: match the inventory against CISA's catalog.
- Baseline numbers: oldest runtime, majors behind on core frameworks, open fixable advisories.
Share the baseline with your manager in a one page summary. Resist fixing things quietly before it is shared, since the baseline is what lets you show progress.
Days 31 to 60: fix and stabilize
- Fix known exploited and reachable findings, taking the smallest change that works.
- Update patch and minor versions in small batches with tests.
- Turn on automated update pull requests, which GitHub describes as keeping dependencies current even when they have no vulnerabilities.
- Add or strengthen tests around the code that calls the riskiest libraries.
- Record exceptions with compensating controls and review dates.
Days 61 to 90: plan the big ones
- Rank major upgrades by support risk and exposure.
- Start the first one, starting with whichever is nearest to end of life.
- Agree a standing capacity share with product leadership.
- Set the routine: weekly review of update pull requests, monthly check of findings, quarterly major.
- Present a second baseline and compare with the first.
Plan at a glance
| Window | Goal | Evidence of progress |
|---|---|---|
| 1 to 30 | Visibility | Baseline one pager |
| 31 to 60 | Urgent fixes, cheap updates | Exploited items closed |
| 61 to 90 | Major plan, routine | First major started, cadence set |
Pitfalls for newcomers
- Updating everything on day three. It breaks things and costs trust.
- Blaming predecessors. The previous team likely had the same incentives you will face.
- Skipping the tests. Without them, every update is a gamble.
- Ignoring the build and container layer.
Getting buy in
Frame the work around response time: how long it would take to ship a fix for a critical advisory today, and how long it should take. That is the number that gets budget. OWASP describes updates as an ongoing plan for the lifetime of the application, which supports asking for standing capacity rather than a one time project.
After day 90
Keep the baseline report monthly. Within a few quarters the trend line will tell the story better than any single report.
Safeguard's SBOM and dependency scanning lists direct and transitive packages with their versions, and reachability analysis shows which outdated or vulnerable ones your code actually calls. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how continuous monitoring reports new findings, so your baseline stays current after day 90.
Quick check
What should I tell my manager first?
The baseline: what is exploited, what is near end of life, and how long a critical fix would take today.
Should I rewrite instead?
Rarely as a first move. Rewrites carry their own dependency choices. Get visibility and stabilize first.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- Status of Python versions
- Node.js releases
- About version updates, GitHub Docs
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
Last reviewed: 19 October 2026.
