Give the auditor evidence that shows scanning ran repeatedly, covered every in-scope repository, and produced findings you worked through. That means a coverage list, a run history, a full findings export for the period, and closure records. A single screenshot of a clean report proves almost nothing.
What the auditor is trying to establish
Three things. First, scanning exists and is configured. Second, it operated throughout the audit period, not just last week. Third, findings were handled according to your policy. Each needs a different artifact.
SOC 2 reports come from independent CPAs, so expect the auditor to design their own tests. Your job is to make complete, dated data easy to produce.
The four artifacts
| Artifact | Proves | Typical source |
|---|---|---|
| Coverage list | Every in-scope repo and service is scanned | Org settings export, repo inventory |
| Run history | Scans happened on a schedule or on each change | CI run logs, scanner history |
| Findings population | The full set of issues detected in the period | Scanner or tracker export |
| Closure records | Issues were fixed or excepted on time | Tickets, PRs, rescans |
Coverage is the one teams forget. If you have 40 repositories and scan 31, the auditor will find the other nine. Reconcile your repository list against scanner coverage monthly.
Make the scan automatic at two points
GitHub documents that Dependabot scans the default branch and sends alerts both when a new vulnerability is added to its advisory database and when your dependency graph changes. That gives you detection that does not depend on someone remembering to run a command. Add a pull request check as well, so new vulnerable dependencies are caught before merge. GitHub's dependency review shows added, removed and updated dependencies and flags known vulnerabilities in a pull request.
Handle exports carefully
Exports should include the date range, a count, and the filter used. If you filter out low severity items or archived repositories, say so in a note. A filter you did not disclose looks like concealment even when it was innocent.
Keep a monthly snapshot in a dated folder. If your tool only shows current state, the snapshot is the only way to show what was open on a past date.
What to leave out of the packet
- Screenshots with no date or tool name visible.
- Findings from out-of-scope systems, which invite scope creep.
- Claims such as "zero vulnerabilities". A clean report on a given day says little about the period, and the claim may be wrong tomorrow.
A simple routine
- First week of the month: export findings and coverage.
- Reconcile coverage against the repo list.
- Save both in the evidence folder with the date in the file name.
- Sample five closed items and confirm the trail is intact.
Try it yourself
Open the demo and see how monitoring runs continuously and records changes over time. Think about which pieces would become your dated exports.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning, continuous monitoring and compliance and evidence automation help keep dated scan and findings records in one place. Free scan: https://gold.safeguard.sh/scan.
Quick check
Is one clean scan report before the audit enough?
No. The auditor wants proof scanning ran over the whole period and that findings were handled.
How do I prove which repositories were covered?
Export the scanner's coverage list and reconcile it against your repository inventory each month.
Sources
- GitHub Docs, About Dependabot alerts
- GitHub Docs, About dependency review
- AICPA and CIMA, SOC suite of services
Last reviewed: 19 October 2026.
