A good way to secure dependencies is a five step loop: know what you ship, pin it, scan it, rank what you find, and fix on a routine. You can start with free tools for the first three steps. Buy or build more only when ranking and fixing become your bottleneck.
Step 1: know what you ship
You cannot secure what you cannot list. Generate an inventory of direct and transitive packages for every repository, from the lockfile rather than the manifest. Manifests say what you asked for. Lockfiles say what you got.
Most teams are surprised by the transitive count. A project with 30 direct dependencies often resolves to several hundred packages.
Step 2: pin versions and commit lockfiles
Unpinned ranges mean two builds of the same commit can ship different code. Commit your lockfile, install from it in CI, and fail the build if it drifts. This is free and removes a whole class of surprise.
Step 3: scan on a schedule and on every change
Scanning only at release is too late. Scan on pull requests so new problems are caught while the author still remembers the change, and rescan stored inventories daily, because advisories are published after you ship.
Step 4: rank findings before you assign them
A raw list sorted by severity will bury a small team. Add two questions: is the vulnerable code actually reachable from your application, and is there a known exploit? Reachability and exploit status together usually shrink the urgent list a lot. Tools differ widely in whether they do this, so test it on your own code.
Step 5: fix on a routine
Pick a weekly slot for dependency updates. Small, frequent upgrades are easier to review than a yearly jump. Automated pull requests help, but keep a human reviewer and a passing test suite as the gate.
Where simpler is enough
If you have one small app, a lockfile, a built in update bot and a free scanner may be all you need. The case for a fuller platform builds with repository count, language mix, audit pressure from customers, and the time your team spends triaging.
A common failure pattern
Teams often buy a scanner first and skip steps one and two. The scanner then reports against a guessed inventory, builds drift between environments, and the first report looks alarming for reasons that are easy to fix. Doing the free groundwork first means any tool you add later starts from accurate data and gives you a fair read on its value.
It also helps to name an owner. A weekly update slot with no owner is a calendar entry, not a process. One person, even part time, who looks at the list every week is worth more than another tool.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how many transitive packages appear beyond the direct ones. That gap is Step 1.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and policy gates. You can try a free scan of a repository without setting anything up.
Quick check
Do I need to scan transitive dependencies?
Yes. Most vulnerable packages that reach production arrive as transitive dependencies, and they are not in your manifest.
Is a lockfile a security control?
It is a reproducibility control that supports security. It makes scans match what you actually deploy.
Last reviewed: 19 October 2026.
