Audit dependency scanning by walking through four stages and asking the same questions at each: is it on, is it required, does it read the real tree, and does it leave a record. Gaps usually show up in the last two. Use this checklist and write down a yes, no or unknown for each line.
How to use it
Pick one representative repository. Answer each question from evidence, such as a config file, a pipeline run or a log, not from memory. Mark unknowns honestly. Then repeat for your most sensitive service.
Stage 1: IDE or local
- An editor extension or CLI is documented in onboarding.
- It uses the same policy as CI, or the differences are known.
- Lock files are committed, so local and CI trees match.
- Developers know it is guidance and not the control of record.
Stage 2: Pull request
- A dependency check runs on every pull request that changes dependency files.
- It is a required check on the protected branch.
- It reads lock files and shows transitive changes.
- The failure rule is written down and developers can find it.
- Exceptions need a named approver and an expiry date.
- The failure message tells developers what to do next.
Stage 3: Build
- Installs in CI use a frozen, lock file based command that fails on mismatch.
- The scan runs against the resolved tree, and container images are scanned too where relevant.
- An SBOM or dependency inventory is stored for every release.
- The vulnerability data in use is current, and its timestamp is visible.
- Release is blocked, or at least flagged, on agreed findings.
Stage 4: Registry proxy or approved list
- Build runners and developers fetch packages through one controlled source.
- Direct access to the public registry from runners is blocked, or at least monitored.
- Rules cover known malicious packages and a hold on very new releases, if your policy calls for it.
- Private package names are protected against public name collisions.
- There is a documented exception path.
Stage 5: After release
- Deployed versions are mapped to stored inventories.
- Re-scans run on a schedule and on notable new advisories.
- Every service has an owner who receives alerts.
- Results feed a tracker with due dates.
Scoring yourself
| Result | Meaning | Next step |
|---|---|---|
| Mostly yes at stages 2 and 3, no at 4 and 5 | Strong at change time, blind afterward | Add scheduled re-scans first |
| Yes at 1, no at 2 | Advice without enforcement | Add a required pull request check |
| Many unknowns | Evidence gap | Capture configs and run records before changing tools |
| Yes everywhere, no records | Hard to prove | Store outputs and exception logs |
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings from different sources land in one queue with owners and priorities, which is the outcome this checklist aims at.
Where Safeguard fits
Safeguard covers dependency scanning, SBOM generation, policies and gates, and compliance and evidence automation for keeping the records. Start with the free scan at gold.safeguard.sh/scan. For the overview of the four stages, see where dependency scanning should run.
Quick check
How often should we run this audit?
Quarterly is a reasonable rhythm, and again after any major pipeline change.
What if we answer unknown to many items?
That is a finding in itself. Gather the evidence first, then decide what to change.
Last reviewed: 19 October 2026.
