To find the open source you use, collect from several places and merge them: lockfiles and manifests in source control, software bills of materials from builds, contents of container images, and download logs from your package proxy. Each source misses something the others catch.
Why one source is not enough
Source repositories show what developers declared. They miss packages installed in a build script, copied into the repo or added in an image layer. Container images show what actually shipped but not why. Proxy logs show what was downloaded, including by laptops and experiments that never reach production.
An inventory built from one view gives false comfort. Use at least two and compare.
The four sources compared
| Source | Shows well | Misses |
|---|---|---|
| Lockfiles and manifests | Direct and resolved transitive dependencies per repository | Vendored code, packages installed by scripts, system packages |
| Build time SBOMs | Exact resolved set for a specific build | Anything outside the build, older deployed versions |
| Container image contents | Operating system packages and what runs in production | Which team owns it, and the reason it was added |
| Proxy or registry logs | Everything downloaded, by whom and when | Whether it ended up in a product |
Steps to build the first inventory
- List repositories. Start with the ones that deploy to production and the ones that ship to customers.
- Scan manifests and lockfiles for each. Record package, version and ecosystem as a package URL so names do not clash across ecosystems.
- Generate an SBOM at build time in a standard format and store it with the build artifact.
- Scan production container images and record the base image too.
- Pull a month of proxy logs and list packages that appear there but not in any repository. Those are your gaps.
- Assign an owner to every product, even if it is a team and not a person.
Keeping it current
A one time spreadsheet is stale within weeks. Generate the inventory on every build and store the output. Track change over time: new packages, removed packages and version drift. Ask that every release record its SBOM, so you can answer questions about a past version.
Questions the inventory should answer in minutes
- Which products use this package and version?
- Which packages have no active maintainer?
- Which licenses are present in products we ship?
- Which versions are more than a set number of releases behind?
If you cannot answer the first question within an hour when a serious advisory lands, the inventory is not ready.
Try it yourself
Click through it at your own pace, or open it full screen. Look at direct versus transitive packages and how many there are.
Quick check
Should the inventory include dev dependencies?
Yes, but label them. Build tools can run with access to secrets, so they matter even if they do not ship.
Is a spreadsheet acceptable?
Only as a very first step. It cannot stay accurate without automation.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
