Yes. When a security check passes, the status line is enough. A comment that says "no issues found" adds a notification, a thread entry and no information the green check did not already give. Save comments for findings that need a person to act.
What a green check already says
Every pull request page shows check results next to the merge button. A passing check there is a complete message. Adding a comment duplicates it, and across a team that opens dozens of pull requests a day, the duplicates add up to hours of scrolling past text that means nothing.
There is also a trust effect. If the bot comments on every pull request, developers learn to treat its comments as background. If it speaks only when something is wrong, each comment carries weight.
Where a little output is still useful
Silence in the conversation does not mean silence everywhere. Keep the detail one click away:
- The check run page can list what was scanned, how long it took and the rule set version.
- A job summary can hold counts and a short table. GitHub combines step summaries into one page on the workflow run, so the detail lives there and not in the thread.
- A log line can note which manifests and languages were covered.
That gives an auditor or a curious engineer the full record without making everyone else read it.
Two exceptions worth making
| Situation | Comment? | Why |
|---|---|---|
| Check passed but coverage was partial | Yes, once | Silence would imply full coverage |
| Previously failing finding is now fixed | Optional, one line | Confirms the fix landed |
| Check skipped by path filter | No, but show status | Skipped is a status, not news |
| Everything clean | No | The green check says it |
The first exception matters most. A pass on a scan that could not parse a lockfile is not the same as a pass on a full scan. Say so in plain words, and say it once.
Keep status descriptions short
The status line itself often accepts a short description. Use it. "No new high severity findings" is more useful than "Passed". It costs no extra notifications and answers the question a reviewer has when glancing at the page.
A note on skipped checks
GitHub's protected branch rules treat skipped required checks as acceptable to merge, so a skipped security job can look like a pass. If a path filter might skip your security job, make that visible in the status text instead of relying on silence. Our post on why a skipped security check can still let a pull request merge covers the mechanics.
Safeguard checks on pull requests can report a result and keep detail in the scan record. You can run a free scan to see how a clean result reads.
Quick check
Is a positive comment ever worth posting?
Occasionally, such as when a long standing finding is finally fixed. Keep it to one line and do not do it on every pull request.
What if a team wants proof the scan ran?
Point to the check run and job summary, which record the run without adding to the thread.
Sources
Last reviewed: 19 October 2026.
