Every scan report should carry a short coverage statement: what was scanned, what input was used, which ecosystems were parsed, the date of the advisory data, and the known gaps. Without it, a reader sees "zero findings" and assumes everything was checked.
Why add one
A report is read by people who were not in the room. An auditor, a customer or a new teammate cannot tell a clean result on a full lockfile from a clean result on an empty folder. A statement of scope turns an ambiguous number into a claim that can be checked.
It also protects you. If a gap is written down at the time, a later finding in that gap is a known limit and not a surprise. Other posts in this series cover individual gaps, for example C and C++ libraries, CDN scripts and end of life software.
The template
Copy this into the report header or the pipeline summary.
Scan coverage statement
Target: repository or image name, commit or digest
Input type: lockfile | manifest | built image | SBOM
Files read: list of lockfiles and manifests found
Components found: number, by ecosystem
Advisory data: source names and the date of the data used
Tool and version: name, version, ruleset
Not covered: vendored code, CDN scripts, firmware, runtime
versions, other known gaps
Run date: date and time
Reviewer: name or role
Field by field
| Field | Why it matters |
|---|---|
| Input type | A manifest is an estimate, a lockfile is exact |
| Files read | Shows whether every project in a monorepo was seen |
| Components by ecosystem | A zero here means the scan did not look |
| Data date | Advisory data changes, so a result has a shelf life |
| Not covered | The part most reports omit |
OSV-Scanner's documentation shows why input type belongs in the statement: versions read from manifests are best effort and may not match what is installed.
Make it automatic
- Have the pipeline write the statement from facts it already holds, such as the files it parsed and the tool version.
- Fail the job if components found equals zero for a project that has a lockfile.
- Store the statement with the report as an artifact, so you can show it later. See what evidence to keep for each release scan.
- Review the not covered list each quarter and remove items once they are covered.
Keep the language factual. Say "not covered" and name the gap, rather than "low risk".
Safeguard's compliance and evidence automation collects scan outputs for review, and the free scan at https://gold.safeguard.sh/scan shows the components found in a manifest.
Quick check
Is a coverage statement the same as a scan report?
No. The report lists findings, the statement describes what the scan could and could not see, so readers can judge the result.
Who should write the not covered list?
The person who owns the scanner setup, reviewed by the security lead, and updated whenever coverage changes.
Sources
Last reviewed: 19 October 2026.
