A workable dependency policy fits on one page. It answers five questions: what may we add, how do updates arrive, how fast do we patch, who approves exceptions, and how do we remove things. Write the answers down, enforce what you can in the pipeline, and review the policy twice a year.
Why write one
Most dependency problems are decision problems. Someone added a package because it saved an afternoon, and nobody decided whether the team could maintain the risk. A policy turns that into a short conversation with a known answer. It also gives auditors and customers something concrete when they ask how you manage third party code. No standard prescribes the content, so the template below is a starting point, not a requirement.
The template
1. Adding a dependency
- Check whether the standard library or an existing dependency already does the job.
- Look at maintenance: recent releases, number of active maintainers, how issues are handled.
- Check the license against your approved list.
- Check what it pulls in. A small package with a large tree of transitive dependencies is a large decision.
- Record the reason in the pull request. For significant choices, write an architecture decision record.
2. Versions and lockfiles
- Commit lockfiles for applications.
- Build from the lockfile in CI, not from a fresh resolution.
- Do not use unpinned latest tags for production images or build tools. Google's release engineering material describes hermetic builds as depending on pinned versions of tools and libraries.
3. Updates
- Automated update pull requests run on a schedule, grouped to keep review load manageable.
- Updates pass the same tests and checks as any change.
- Major version updates get a human read of the changelog.
- Consider a short delay before adopting brand new releases, a setting some update tools offer. Check your tool's documentation.
4. Patch targets
Set a target by severity and exposure, and write the numbers that suit your business, for example: critical and reachable in days, high within a few weeks. The right numbers are yours to choose. What matters is that they exist and are measured.
5. Exceptions
- Anyone may request one, with a reason, an owner and an end date.
- A named person approves.
- Exceptions are listed in one place and reviewed monthly.
6. Removal
- Remove unused dependencies when found.
- Replace abandoned ones on a plan, not in a panic.
7. Inventory
- Keep a current software bill of materials for each release.
Enforcing it
A policy nobody enforces is a wish. Turn as many rules as you can into checks: block disallowed licenses, fail builds that do not use the lockfile, require review for new dependencies, and alert on known vulnerable versions. Keep human judgment for the rest.
Keeping it short
Resist adding clauses after every incident. If the page grows past one side, move detail into procedures and keep the policy for decisions.
Safeguard supports this with SBOM and dependency scanning, reachability analysis to prioritize, and policies and gates that enforce rules on pull requests. The free scan is at gold.safeguard.sh/scan.
Quick check
Do we need fixed patch deadlines?
You need targets you can measure. Pick numbers by severity and exposure that your team can actually meet, and report against them.
Who should own the policy?
Engineering leadership, with security as a reviewer. Ownership by a single person ensures it gets updated.
Sources
Last reviewed: 19 October 2026.
