Open source hides in six places a lockfile does not cover: base image packages, vendored or copied source, CI actions and build plugins, binaries committed to the repository, front end bundles, and tools installed by scripts. An audit inventory that stops at the lockfile misses all six.
Why lockfiles feel complete
A lockfile is exact, machine readable and easy to scan. The GitHub dependency graph, for example, is a summary of the manifest and lock files in a repository plus anything submitted through its dependency submission API. That is useful, and it also defines the boundary: what is not in a manifest or submitted is not in the graph.
The six places
| Place | What lives there | How to find it |
|---|---|---|
| Base images and OS layers | System libraries, runtimes, shells | Inventory the built image, not the Dockerfile |
| Vendored or copied source | Libraries pasted into a folder | Search for folders named vendor, third_party, lib; look for license headers |
| CI actions and build plugins | Workflow steps, Gradle or Maven plugins | Read the workflow and build files |
| Committed binaries | Jars, DLLs, shared objects | Search the repository for binary files |
| Front end bundles | Minified libraries | Source maps, bundle analysis |
| Install scripts | Tools fetched by curl or package managers at build time | Read the build scripts |
How the OpenSSF Scorecard helps
The OpenSSF Scorecard documents checks that point at these areas. Its Binary-Artifacts check looks for generated executables in a source repository, and its Pinned-Dependencies check looks for unpinned dependencies in Dockerfiles, shell scripts and GitHub workflows used during build and release. Running those checks against a target's own repositories is a quick way to find places where the inventory is likely thin.
A one hour sweep
- List every repository from the source host.
- For each, search for committed binaries and vendor folders.
- Read each Dockerfile and workflow for fetched tools.
- Generate an inventory from each deployed image.
- Compare with the seller's file and note differences.
What to do with findings
Add each hidden item to the inventory with a source note: where it was found and how. For vendored code, identify the upstream project and version if you can, since without that it cannot be matched to vulnerability data. For binaries with no clear origin, mark them unidentified and ask for the build recipe.
Safeguard's asset discovery and SBOM generation cover repositories and container images, so the image based comparison above is a scan rather than a manual task. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice which findings come from operating system layers rather than application dependencies.
Quick check
Is a Dockerfile enough to know what is in an image?
No. A Dockerfile shows instructions, but the base image and package installs resolve at build time. Inventory the built image.
Are dev dependencies in scope?
For shipped software they usually do not reach customers, but they run on developer machines and in CI. Record them with a scope label so reviewers can filter.
Sources
Last reviewed: 19 October 2026.
