Search every repository for the manifest and lock file names of each ecosystem you use, list the hits by repo and path, and then compare against what you believe you run. The gaps, such as repos with a manifest but no lock, or forgotten directories, are the findings. Repeat the search on a schedule.
Why a manual list is not enough
Teams usually know their main services. They forget the internal tool, the old prototype, the data script with its own requirements file, the sample app inside the docs folder. Those are exactly the places where nobody watches advisories.
Inventory first, then control. You cannot lock what you cannot find.
File names to search for
Use names that official docs establish:
| Ecosystem | Manifest or lock files to look for |
|---|---|
| npm | package.json, package-lock.json |
| Rust | Cargo.toml, Cargo.lock |
| Go | go.mod, go.sum |
| .NET | project files with PackageReference items, packages.lock.json |
| Gradle | gradle.lockfile, buildscript-gradle.lockfile |
| PHP | composer.json, composer.lock |
| Maven | pom.xml |
| Python | requirements files, pylock.toml |
Add your own ecosystems. The Gradle docs say lock state lives in a gradle.lockfile at the root of each project or subproject directory, and buildscript locks use a separate name. NuGet allows a project specific name, packages.project_name.lock.json, when several projects share a directory.
Steps
- Search. Use your code host's search or clone and run a file search. Include archived and forked repos if they still deploy.
- Normalize. Record repo, path, ecosystem, and whether a lock sits next to the manifest.
- Join. Match each repo to an owner using a service catalog or CODEOWNERS file. Unowned hits go on a list of their own.
- Compare. Check the list against the services you believe exist, and against what is actually deployed.
- Schedule. Rerun monthly, and diff the results.
What the results tell you
- A manifest with no lock: an uncontrolled install.
- A lock with no manifest change in years: possibly abandoned.
- Many manifests inside one repo: a monorepo that needs per directory ownership.
- A repo that deploys but has no manifest: likely vendored or built another way, so check how.
Nested and generated files
Search inside subdirectories, not only the root. Also treat generated lock files with care: if a build creates them at CI time and does not commit them, your search will miss them. Note those repos separately and ask whether the lock should be committed.
Try it yourself
Open the demo and look at how a dependency inventory shows direct and transitive components in one view. Pay attention to how each component is tied back to where it came from.
Click through it at your own pace, or open it full screen.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Quick check
Do I need to search forks and archived repos?
Only those that still build or deploy something. Archived repos that nothing uses can be listed and ignored.
What if a repo has no manifest at all?
Find out how it gets its code. It may vendor dependencies, use another build tool, or contain only static content.
Sources
Last reviewed: 19 October 2026.
