Developers should be taught how to choose a package, pin and review versions, understand transitive dependencies, read advisories and update on a schedule. Five short lessons with exercises on your own repositories cover this better than a single annual module on supply chain risk.
Why this deserves its own lesson
Most modern applications contain more third party code than first party code. Developers add packages dozens of times a year, often in seconds. Each addition is a security decision, yet it is rarely treated as one.
The OWASP Proactive Controls include Keep your Components Secure for this reason, and the CI/CD risk list includes Dependency Chain Abuse.
Lesson 1: choosing a package
Teach a quick check before adding anything:
- Is it needed, or does the platform already offer this?
- Is it maintained? Look at recent releases and open issues.
- How many dependencies does it bring?
- Does the name look right? Look alike names are a known trick.
Make this a short pull request checklist rather than a policy document.
Lesson 2: versions and lockfiles
Explain what a lockfile records and why committing it matters. Explain ranges, and what a build does when a range lets a new version in. Exercise: change one range in a test project and read the resulting lockfile diff.
Lesson 3: transitive dependencies
Show the full tree of a real project. Most developers have never seen it. Ask them to find the deepest package and name who maintains it. The point is not alarm. It is that a vulnerable package may be one nobody chose directly.
Lesson 4: reading an advisory
Teach four questions: which versions are affected, is there a fixed version, does our code call the vulnerable function and is it reachable from untrusted input. Exercise: take one real advisory and answer all four for your own project.
Lesson 5: updating on a schedule
Teach that small regular updates are cheaper than rare large ones. Agree a cadence and who owns it. Show how to read a changelog for breaking changes before merging.
Summary table
| Lesson | Skill | Exercise |
|---|---|---|
| 1 | Choose | Review a recent new package |
| 2 | Pin | Read a lockfile diff |
| 3 | Map | Walk the dependency tree |
| 4 | Assess | Answer the four advisory questions |
| 5 | Maintain | Schedule and merge one update |
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how many findings drop out once reachability is considered. That is lesson 4 in action.
Where Safeguard fits
Safeguard provides dependency scanning, SBOM generation and reachability analysis, which turn lessons 3 and 4 into something developers can see for their own code. It does not offer training courses. Try the free scan at gold.safeguard.sh/scan.
Quick check
How long should a dependency lesson take?
Short enough to repeat. Thirty to forty five minutes per lesson, spread over weeks, is easier to sustain than a half day.
Should developers memorise advisory databases?
No. They should know the four questions and where to look. Tooling handles lookup.
Sources
- OWASP Top 10 Proactive Controls: top10proactive.owasp.org
- OWASP Top 10 CI/CD Security Risks: owasp.org
Last reviewed: 19 October 2026.
