Yes. A pass only means something relative to what was scanned. Put a short coverage line in the check output: what was scanned, what was skipped and why. Without it, reviewers read a green check as "this change is safe", which is a much bigger claim than the tool made.
The gap between green and safe
A security check reports on the things it can see. If it does not parse a language, cannot resolve a lockfile, skips a path by filter, or times out, the result can still be green. The reviewer sees green and moves on.
Protected branch rules make this easy to miss. GitHub accepts required checks that are successful, skipped or neutral, so a skipped job can let a change merge. The status alone does not tell the reader which of those happened.
What a coverage line contains
Scanned: 2 manifests (package-lock.json, requirements.txt), 14 changed source files (Python, JavaScript)
Skipped: docs/ (excluded path), infra/*.tf (language not enabled)
Rule set: 2026-10-19
Duration: 48 seconds
Four facts, short enough to read at a glance and complete enough to audit.
What to list
| Item | Why it helps |
|---|---|
| Manifests and lockfiles read | Shows dependency coverage |
| Languages analysed | Shows code coverage |
| Paths excluded and reason | Exposes silent gaps |
| Rule or database version | Explains differences between runs |
| Time and any limit reached | Flags partial scans |
Where to put it
Not in a comment on every pull request. Keep it in the check run output or job summary, and in the status description when coverage is partial. GitHub combines step summaries into a single page per workflow run, which is a natural home. Raise a comment only when coverage is notably incomplete, such as a lockfile that failed to parse.
Make partial coverage loud
Treat three cases as louder than a normal pass: a manifest the scanner could not read, a language present in the diff that no rule covers, and a timeout. For each, either fail the check for sensitive repositories or change the status text to "passed with gaps" so it is not mistaken for a full scan.
Tie it to inventory
A coverage line is a per pull request version of a bigger question: does your scanner cover all your repositories and ecosystems? See checking every repository is scanned for the program level view.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what the monitoring view says it covers, and compare that with what you would want in a coverage line.
Safeguard asset discovery and SBOM generation help you see what is in scope before you trust a pass. A free scan lists what was found.
Quick check
Will a coverage line make the output too long?
Keep it to four short lines in the check output. The detail is for people who look, and it stays out of the comment thread.
Should partial coverage fail the check?
For sensitive code paths, often yes. For others, a clear "passed with gaps" status may be enough. It is a policy choice.
Sources
Last reviewed: 19 October 2026.
