Most organizations think about dependencies at two moments: when they add one and when it has a vulnerability. Everything in between is a blind spot. That blind spot is where dependency risk accumulates -- quietly, steadily, until a security incident or a breaking upgrade forces an expensive reckoning.
Dependency lifecycle management is the practice of treating every dependency as a supply chain relationship that requires ongoing attention from adoption through retirement. Here is a practical framework for doing it well.
Phase 1: Selection
Adding a dependency should be a deliberate decision, not an impulse. Every dependency you add is a long-term commitment -- to monitoring, updating, and eventually replacing it.
Evaluation Criteria
Before adding a new dependency, evaluate it against these criteria:
Necessity. Can you achieve the same functionality with existing dependencies or reasonable custom code? A utility function that saves 10 lines of code is not worth the supply chain risk of a new dependency. The left-pad incident was a decade ago, and we still have not fully internalized its lesson.
Maintenance health. Check the basics: when was the last release? How many active maintainers? Are issues being responded to? Are security reports handled promptly? A package with a single maintainer who last committed eight months ago is a risk, regardless of its star count.
Security track record. Has the package had security vulnerabilities before? How were they handled? A package that had vulnerabilities but responded quickly and transparently is better than a package that has never been audited.
Dependency depth. What does this package depend on? Adding one direct dependency might bring in 50 transitive dependencies, each with its own risk profile. Check the full tree, not just the top-level package.
License compatibility. Is the license compatible with your project's license and your organization's license policy? Check this before you write code against the API, not after.
Size and scope. Does the package do one thing well, or is it a kitchen-sink library where you use 5% of the functionality? Smaller, focused packages typically have lower risk.
Documentation
When you add a dependency, document why. A brief note in your project documentation or commit message explaining the rationale saves enormous time when someone later asks "why do we depend on this?" The answer should never be "I don't know, it was here when I joined."
Phase 2: Integration
How you integrate a dependency affects your ability to manage it throughout its lifecycle.
Pin Versions
Use exact version pinning or lock files. Do not rely on semver ranges for production dependencies. Semver is a social contract, and it is broken regularly. A "minor" version bump that introduces a breaking change should not automatically deploy to production.
// Do this
"lodash": "4.17.21"
// Not this
"lodash": "^4.17.0"
Lock files (package-lock.json, poetry.lock, go.sum) provide deterministic builds. Commit them. Always.
Minimize Surface Area
Import only what you need. If you are using three functions from a large utility library, consider importing them directly or wrapping them in an internal module. This serves two purposes:
- It reduces the blast radius if the dependency is compromised -- your code only uses a small, known surface area
- It makes replacement easier -- you only need to find an alternative for three functions, not the entire library
Add to Your SBOM
Ensure your SBOM generation captures the new dependency accurately. Verify that the PURL, version, license, and hash are correct. This is the foundation for all subsequent lifecycle management.
Phase 3: Monitoring
This is the phase most organizations neglect. Once a dependency is added, it needs continuous monitoring.
Vulnerability Monitoring
Subscribe to vulnerability alerts for your dependencies. This can be automated through:
- GitHub Dependabot or GitLab Dependency Scanning
- A dedicated SCA tool
- SBOM-based monitoring through a platform like Safeguard
The key is continuous monitoring, not periodic scanning. A vulnerability disclosed on Monday should be on your radar Monday, not at your next quarterly security review.
Maintainer Health Monitoring
Track the health indicators we discussed in our maintainer succession planning post: commit frequency, issue response time, maintainer count, and release cadence. Set alerts for significant changes -- a maintainer who goes from weekly commits to silence is an early warning signal.
License Change Monitoring
Packages sometimes change licenses between versions. A package that was MIT in version 2.x might be SSPL in version 3.x. If you upgrade without checking, you may inadvertently violate your license policy.
Deprecation Monitoring
Many packages publish deprecation notices long before they stop working. Monitor for these notices so you can plan migration on your timeline rather than being forced into it.
Phase 4: Updating
Keeping dependencies updated is one of the most effective security practices available. Most supply chain vulnerabilities are exploited in outdated versions where patches already exist.
Update Strategy
Automated updates for minor/patch versions. Use tools like Dependabot or Renovate to automatically create PRs for minor and patch updates. If your test suite is comprehensive, you can auto-merge patch updates.
Managed updates for major versions. Major version updates require human review. They may include breaking changes, license changes, or significant behavioral differences. Plan these as work items, not afterthoughts.
Emergency updates for security patches. Have a fast-track process for security updates. When a critical vulnerability is patched, you need to deploy the fix in hours, not weeks. This process should be documented and practiced.
Update Testing
Every dependency update should pass your full test suite. If your test suite is not comprehensive enough to catch dependency regressions, that is a separate problem that needs addressing. At minimum, maintain integration tests that exercise your critical code paths including the functionality provided by major dependencies.
Update Cadence
Set a regular cadence for reviewing and applying updates. We recommend:
- Security patches: Same day or next business day
- Patch versions: Weekly (automated)
- Minor versions: Bi-weekly (automated with review)
- Major versions: Quarterly (planned, manual)
Phase 5: Retirement
Dependencies do not live forever. At some point, every dependency needs to be replaced, removed, or absorbed.
Triggers for Retirement
- Abandonment. The maintainer stopped maintaining it. No responses to issues, no releases, no activity.
- Better alternative. A better-maintained, more secure, or more performant alternative exists.
- Reduced need. Your application evolved and no longer needs this functionality, or the language/runtime now provides it natively.
- License change. The dependency changed to an incompatible license.
- Security concern. Persistent security issues that the maintainer is not addressing.
Retirement Process
- Identify a replacement (or determine that the functionality can be removed or internalized)
- Create a migration plan with estimated effort and timeline
- Implement the migration behind a feature flag if possible
- Test thoroughly -- both the new implementation and the removal of the old dependency
- Remove the old dependency from your manifests, lock files, and SBOM
- Update documentation to reflect the change
The Fork Decision
Sometimes the right answer is to fork an abandoned dependency rather than migrating to a different one. This makes sense when:
- The dependency is deeply integrated and migration cost is very high
- The codebase is stable and well-understood
- You only need to maintain it (security patches), not evolve it
- No suitable alternative exists
Forking carries its own costs -- you are now a maintainer. But for critical infrastructure dependencies, it may be the lowest-risk option.
How Safeguard.sh Helps
Safeguard.sh supports every phase of the dependency lifecycle. Our SBOM platform evaluates dependency health at selection time, monitors for vulnerabilities and maintainer changes continuously, tracks license and deprecation status, and helps you plan retirement by identifying which dependencies are approaching end-of-life. Our Guardrails enforce lifecycle policies automatically -- blocking additions that fail evaluation criteria, flagging dependencies that exceed age thresholds, and alerting when maintainer health declines. Complete lifecycle management is the difference between dependencies that serve you and dependencies that surprise you.