Yes, in part. Scanners that read manifests and lockfiles do not need a working build, so they can inventory dependencies in code that no longer compiles. The trade is precision: without resolution, version ranges and transitive packages may be guessed, and findings need more careful review.
Two ways a scanner learns your dependencies
A scanner can read the files you committed, or it can run your build and ask the build tool what it resolved. They answer different questions.
| Approach | Needs a working build | Strength | Weakness |
|---|---|---|---|
| Manifest and lockfile reading | No | Fast, safe to run anywhere | Unpinned ranges are approximations |
| Resolved tree from the build tool | Yes | Exact versions and transitive packages | Fails when the toolchain is gone |
Maven's dependency plugin shows the second approach: its tree goal displays the dependency tree for a project and requires a Maven project to be executed, so it cannot help when the build is broken beyond repair.
Steps for a broken build
- Start with lockfiles. Where a lockfile exists, it records exact versions and gives you a precise answer without a build. The Gradle documentation describes a lockfile as recording the exact versions of dependencies used, and advises keeping it in source control.
- For directories without a lockfile, scan the manifest and mark results as approximate.
- Pick the five most important broken directories and try to restore a build in a container with the old toolchain. Use a pinned old image, not your laptop.
- Where a build cannot be restored, record that fact as a known coverage gap with an owner.
- Review the findings for the approximate directories by hand before gating on them.
Treat approximate results honestly
With a version range such as "1.2 or higher", a manifest scan cannot know what was actually shipped. Two safe options exist.
- Report the finding as "possible" and ask the owning team to confirm the deployed version.
- Cross check against what is running in production, such as the version in a container image or an artifact repository.
Do not suppress approximate findings to keep numbers low. A quiet dashboard that hides the old code is the outcome you are trying to avoid.
A broken build is itself a finding
Code that cannot be built cannot be patched with confidence. If a library in that directory has a known vulnerability, you cannot rebuild and ship a fix quickly. Put this on the risk register as a separate line: "cannot be rebuilt". It is a good argument for restoring the build or retiring the service, and it changes how urgent the vulnerability is.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how findings can be tracked with an owner and status. Use the same fields for your "cannot be rebuilt" items.
Where Safeguard fits
Safeguard's dependency scanning reads manifests and lockfiles, and reachability analysis helps decide which findings matter once you have an inventory. You can try a free scan at https://gold.safeguard.sh/scan before connecting anything larger.
Quick check
Is a manifest only scan good enough for compliance evidence?
It can be a starting point, but state its limits plainly. Say which directories were scanned from manifests only and which from resolved builds.
Should we fix the build first and scan later?
No. Scan now to get an inventory, then use the findings to decide which builds deserve restoring.
Sources
Last reviewed: 19 October 2026.
