Test an SCA tool on the messy parts of your estate: nested lockfiles in a monorepo, base images you did not build, and vendored code. A tool that handles a tidy sample project can still miss half your real dependencies. These checks take an afternoon.
Check 1: nested lockfiles
Put two or three lockfiles in different subfolders of one repository, in different ecosystems if you can. Scan it. Count how many the tool found. The result should list each project separately, so you know which service owns which finding.
If it found only the root, ask how to configure paths, and whether that is a one time setting or per developer.
Check 2: workspace packages
Many monorepos use workspaces, where packages depend on each other. Check that internal packages are not reported as unknown or external, and that their external dependencies are attributed correctly.
Check 3: base image contents
Build an image from a standard base and scan it. Then compare the findings to your application's own dependency list. You should see operating system packages as well as application libraries. Findings in the base image are often the largest group, and the fix is usually to change the base, not your code.
Check 4: multi stage builds
Scan the final image of a multi stage build. Does the tool report build time tools that were left behind? Does it miss runtime dependencies copied from earlier stages? Both happen.
Check 5: vendored and copied code
Copy a library's source into your repository without package metadata. A package manifest scanner will miss it. Ask whether the tool can detect copied code by other means, and what it reports when it cannot. The NTIA text says such gaps should be disclosed as known unknowns, and your tool's output should do the same. See known unknowns explained.
Check 6: findings attached to the right owner
For a monorepo, test whether findings can be routed to the owning team, by path or by project. A single long list for the whole repository is hard to act on.
Check 7: scan time at scale
Time a scan of the whole monorepo, then of one changed package. Incremental scanning matters for large repositories.
Record the results
Make a simple table: check, pass or fail, notes. Add it to your scorecard. See how to build an SCA evaluation scorecard.
Safeguard scans repositories and container images as part of SBOM and dependency scanning. Try it on a messy repository with the free scan at https://gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
What to do with failures
A failed check is information, not a veto. Some failures are configuration, such as pointing the tool at the right paths. Some are structural, such as no image support at all. Ask the vendor for each failure whether a fix is a setting, a planned feature, or a gap, and get the answer in writing. Then weigh the structural gaps heavily, since you cannot configure them away.
Quick check
Should I scan the image or the source?
Both. Source shows what you declared, and the image shows what you ship.
Sources
Last reviewed: 19 October 2026.
