Run security checks on draft pull requests if you like, but hold most comments until the pull request is marked ready for review. Authors on a draft are still changing the code, so early comments go stale fast and teach people to ignore the bot.
Why timing changes how comments land
A draft says "not done yet". Comments on unfinished code are often fixed by the next commit anyway. Each one still sends a notification and adds a thread to a page the author is about to rewrite.
Platforms already follow this logic for human reviewers. On GitHub, code owners are not automatically requested for review on a draft pull request, and they are notified when the draft is marked ready. A security bot can follow the same rhythm.
A three stage timing plan
| Stage | What runs | What is shown |
|---|---|---|
| Draft, each push | Fast checks: dependency changes, obvious high confidence issues | Status only, no comments |
| Ready for review | Full check set | Comments, capped, ranked |
| Each later push | Delta check | Only new or changed findings |
The point is to separate feedback for the author from feedback for the reviewer. A draft author wants to know early if something big is wrong. A reviewer wants a clean, short list.
What to run on drafts
Keep draft checks cheap. Dependency review of added packages takes seconds and catches the costliest mistakes. Heavy analysis can wait. If your full scan takes several minutes, running it on every draft push burns runner time and attention for little gain.
Make the draft result visible in the check status so an author who looks can see it. Do not push it into the thread.
What if a risky change is in a draft
A hard stop on a draft is rarely needed, because drafts cannot be merged under normal settings. Exceptions exist: a new package that is known malicious is worth flagging immediately, whatever the state. Reserve that for a very small set of certain signals.
Make the transition explicit
When the pull request moves to ready, run the full check set and post one summary of what is open. That moment is the natural handoff, and it gives the author a single list to work from instead of a trail of earlier notes. Also consider closing out outdated comments from the draft stage so the thread starts fresh.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow the flow from a pull request being opened to the gate result, and note where a draft state would change what you want to show.
Safeguard can run dependency scanning and policy checks on pull requests, and you set what each stage reports. Try the free scan to see current findings.
Quick check
Should security checks run at all on drafts?
A light set is reasonable and cheap. Full analysis can wait for the ready state to save runner time and avoid noise.
Do drafts bypass required checks?
Required checks still apply before a merge. A draft normally cannot be merged until it is marked ready, so the timing question is about feedback, not control.
Sources
Last reviewed: 19 October 2026.
