Teach developers a short checklist they can apply before adding a package: do we need it, who maintains it, what does it pull in, what is its vulnerability and license status, and how will we update it. Then practice on your own lockfile, not a slide.
Why it needs teaching
Most applications are mostly other people's code. Each dependency brings its own dependencies, which brings its own maintainers and its own risks. Developers choose packages quickly, often by popularity or the first search result. A habit of five questions costs about two minutes and prevents many later headaches.
The five questions
- Need: can the standard library or an existing dependency do this?
- Maintenance: when was the last release, and is there more than one maintainer?
- Footprint: how many transitive packages does it add?
- Status: any known vulnerabilities, and what license?
- Update path: who owns upgrades, and how will we hear about new advisories?
A decision table
| Observation | Reasonable response |
|---|---|
| Single maintainer, no release for a long time | Look for an alternative or plan to vendor and own it |
| Large transitive tree for a small feature | Write the small piece yourself |
| Known vulnerability, fix available | Upgrade now |
| Known vulnerability, no fix | Check whether your code reaches the vulnerable function, add a compensating control, record the decision |
| License conflicts with your policy | Do not add it; ask legal |
| Package name looks like a close misspelling of a popular one | Stop and verify the source |
A 45 minute lesson
- Ten minutes: explain direct versus transitive dependencies with a real tree from your own project.
- Fifteen minutes: pairs take a lockfile and answer the five questions for three packages.
- Ten minutes: practice reading an advisory: affected versions, fixed version, how an attacker reaches it.
- Ten minutes: discuss one case where the team chose to accept a risk and how it was documented.
Reinforce at the right moment
Add a pull request template line: "New dependency? Answer the five questions in the description." Have a champion look at the answers in review. For vulnerabilities, a quick explanation of reachability analysis helps developers see why some alerts matter more than others.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive packages are listed, and find one that you would not have chosen on purpose.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning plus reachability analysis, so a lockfile can be inventoried and sorted. You can try a free scan.
Quick check
Is a popular package always safe?
No. Popularity means more eyes and more attention from attackers. Run the same five questions anyway.
Who should own dependency upgrades?
The team that owns the service, with a champion tracking overdue ones. Name an owner in the repository.
Last reviewed: 19 October 2026.
