Build a dependency inventory in stages: start with customer facing repositories, capture direct and indirect packages from lockfiles or your source host, attach an owner to each repository, and refresh the list automatically on every change. A one time spreadsheet goes stale within weeks.
Why dependencies belong in year one
Most application code is made of other people's code. When a new vulnerability lands, the first question is whether you use the affected package, and in which services. Without an inventory, that takes days of asking around. With one, it takes minutes.
GitHub's documentation on Dependabot alerts says that, once enabled, GitHub generates the dependency graph and creates alerts for vulnerable dependencies it identifies. That is one example of how a source host can supply the raw data, and other tools do the same for more ecosystems.
Stage 1: pick the scope
Use the repository inventory from quarter one and start with services customers touch. Add internal tools later. Do not try for complete coverage in week one.
Stage 2: capture what is really used
Capture both direct dependencies, which your code names, and indirect ones, which your dependencies pull in. Indirect packages are often the larger share, and the ones people forget.
| Source | What it gives | Limit |
|---|---|---|
| Lockfiles | Exact resolved versions | Just for ecosystems that have them |
| Source host dependency graph | Quick, no setup | May not cover every language or build |
| Build time scan | What actually went into the artifact | Needs CI work |
| Container image scan | OS packages and bundled libraries | Separate from application manifests |
Prefer the build output when you can, since it reflects what shipped.
Stage 3: attach owners
An inventory entry with no owner is trivia. Add the team name to each repository. When an advisory arrives, you then know who to tell.
Stage 4: keep it fresh
Refresh on each merge, not once a quarter. If your inventory is produced by CI, it updates itself. Set an alert for repositories with no recent inventory data, since that usually means a scan broke.
Try it yourself
This demo shows a dependency inventory with direct and indirect packages. Click into a package and look at which repository uses it and which version.
Click through it at your own pace, or open it full screen.
Use the inventory for three questions
- Are we affected? Search by package and version.
- Where? The repositories and owners.
- Is it reachable? Whether the vulnerable code is actually called. Reachability analysis narrows long lists to what needs action first.
Signs the inventory works
- A new advisory can be answered in an hour.
- Every entry has an owner.
- New repositories appear in it without a ticket.
Safeguard provides SBOM and dependency scanning and reachability analysis for this, and the free scan shows a first view of one repository.
Quick check
Should the inventory include transitive dependencies?
Yes. Indirect packages are often the majority and are where surprises come from.
Is a source host dependency graph enough?
It is a good start. Add build time or image scans for what actually ships, and for ecosystems it does not cover.
Sources
Last reviewed: 19 October 2026.
