You prove dependency scanning runs on every build with three artifacts: the pipeline file that calls the scan, a run history showing it executed on recent commits, and one example where a finding blocked or changed a merge. A screenshot of a dashboard alone is weak evidence.
Why a claim is not enough
Enterprise security teams read hundreds of answers that say "we scan dependencies." The follow-up is usually "show me." If your first enterprise deal is waiting on that follow-up, the quality of your evidence matters more than the tool name.
Evidence is stronger when it is generated by the system, not typed by a person. A pipeline log carries a timestamp and a commit. A slide does not.
The three pieces of evidence
| Evidence | What it shows | How to produce it |
|---|---|---|
| Pipeline definition | The scan step exists and is part of the default path | Export the workflow file with the scan job highlighted |
| Run history | The step ran on real commits, not once | Export a list of runs for the last 30 to 90 days with pass or fail |
| A blocked or fixed example | Findings change behaviour | Link one pull request where a finding was fixed before merge, with identifiers redacted |
Keep the exports in a dated folder so the next buyer gets the same pack.
Make the scan hard to skip
Evidence is only honest if the scan cannot be quietly bypassed. Check these before you send anything:
- The scan job is a required status check on the default branch.
- Admins are not exempt from the branch rule, or exemptions are logged.
- The job fails closed. If the scanner cannot fetch its data, the build should not silently pass.
- Scheduled rescans exist too, because a build that was clean last month can be vulnerable today when a new advisory lands.
That fourth point is easy to forget. A build-time scan is a snapshot. New disclosures appear after your last build, so mention both the on-commit scan and the scheduled one.
How to word the answer
Plain statements work best:
"Dependency scanning runs on every pull request and on a daily schedule against the default branch. It is a required check, so a failing result blocks merge unless a named approver records an exception. We can share the pipeline file and the last 60 days of run history."
Do not write "all" or "never" unless you have checked every repository. If two legacy repos are not covered, say so and give the date they will be.
What a buyer reviewer looks for next
Expect these follow-ups: which ecosystems are covered, whether transitive dependencies are included, what happens to a critical finding, and who approves exceptions. Having a one page note that answers each is faster than answering by email. For the exception question, see how to document a vulnerability you have not fixed yet.
NIST's Secure Software Development Framework, SP 800-218, is a common reference for what secure development practices should exist. It is a set of practices, not a certification, so describe your pipeline as aligned to its practices only where you can point at the control.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a finding turns into a failed check on the pull request, which is the "blocked example" buyers like to see.
Safeguard runs SBOM and dependency scanning and can enforce policy gates on pull requests. You can try a free scan on a repository before building your evidence pack.
Quick check
Is a dashboard screenshot enough evidence?
Usually not on its own. Pair it with the pipeline file and run history, which carry timestamps and commits.
Do I need to scan on a schedule if I scan every build?
Yes, if you want to catch advisories published after the last build. A scheduled rescan covers that gap.
Sources
Last reviewed: 19 October 2026.
