Run a file census: search the whole repository for build and manifest files such as pom.xml, build.gradle, package.json, requirements.txt, go.mod and Makefile, then group the results by directory. The census tells you which ecosystems your new scanner must support before you promise anyone full coverage.
Why a census comes first
A legacy monorepo grows by accretion. Someone added a Gradle service in 2017, a Python tool in 2019, and a Maven module nobody has touched since. Nobody holds the whole list in their head.
If you onboard a scanner without that list, you will find out about the gaps one at a time, usually when a team says "but our service was never scanned". A census turns that surprise into a spreadsheet you build in an afternoon.
Step by step
- Check out a clean copy of the default branch. Do not use a working copy with leftover build output.
- Search for manifest and build files. Include files with unusual names, such as a build script called build.sh in a service directory.
- Group results by top level directory and by ecosystem.
- Mark each directory as active, quiet or abandoned, using the date of its last commit.
- Note which directories have a lockfile and which do not.
A starting command for the search:
git ls-files | grep -E '(^|/)(pom\.xml|build\.gradle(\.kts)?|package\.json|requirements[^/]*\.txt|pyproject\.toml|go\.mod|Cargo\.toml|Gemfile|composer\.json|Makefile)$'
Using git ls-files instead of find keeps untracked build output out of the results.
What the output tells you
| Finding | What it means for onboarding |
|---|---|
| Many pom.xml files with one root pom.xml | A multi-module Maven build; scan from the root and from modules |
| package.json with no lockfile beside it | Versions are not pinned; results depend on resolution |
| Build files in only one directory of a language | Probably a one-off tool; ask who owns it |
| Makefile that calls several package managers | A wrapper; find the real manifests it uses |
Maven's own documentation notes that an aggregator project and a parent project are both POM projects but are not the same thing, so a root pom.xml may only list modules, not define shared dependencies. Check which role each pom.xml plays before you decide where a scan should start.
Handle the awkward cases
Some code has no manifest at all, such as vendored libraries copied into a directory. Add a second pass that looks for directories named vendor, third_party or lib and decide how to treat them. Do not skip this pass, because copied libraries are where old vulnerable versions tend to survive.
Also look for nested repositories or git submodules. A submodule is not part of the monorepo checkout by default, and a scanner will miss it unless you tell it to fetch it.
Write the result as a short table: directory, ecosystem, lockfile present, owner guess, last commit date. This becomes the coverage map you update each week.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an inventory groups components by ecosystem. Your census should produce the same kind of view for your repository.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation work from the manifests and lockfiles it finds, so the census doubles as a checklist of what to point it at. The CLI (version 1.4.0, curl and PowerShell installers) can run locally, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Should the census include test and example directories?
Yes, list them, but mark them separately. You may decide to exclude them from gating later, but you should know they exist and what they depend on.
How often should the census be repeated?
Redo it when a new team joins the repository and at least once a quarter. New build files appear without announcement.
Sources
Last reviewed: 19 October 2026.
