There’s a bit of a potential gap in Snyk’s GitHub integration. This means that you can have the situation where:
You enable GitHub merge queue.
You require Snyk checks.
Everything looks good.
Then your PR hits the queue… and gets blocked.
No failures.
No vulnerabilities.
Just… missing checks.
🧠 What’s actually going on
The issue is subtle:
Snyk’s GitHub integration does not run on merge queue events.
It only runs on:
pull_request
But merge queues use:
merge_group
That difference is everything.
🔧 How Snyk normally works
When you open or update a PR:
Snyk scans dependencies/code
It posts a status check on the PR
You require that check before merge
This works perfectly assumig you are not using merge queues.
When merge queue is enabled:
PR enters queue
GitHub creates a temporary combined branch
It triggers CI using:
Required checks must run again on this combined state
This is the point of validation before merge
💥 The failure mode
Here’s what happens in practice:
Snyk runs on PR → ✅ passes
PR enters merge queue
GitHub expects required checks on
merge_groupSnyk does not run again
❌ Required check is missing → merge blocked
Or worse:
You disable the requirement
Multiple PRs merge
❌ combined vulnerabilities slip through
⚠️ Why this is a real problem (not just tooling friction)
Merge queues change the question from:
“Is this PR safe?”
to:
“Is this PR safe in combination with others?”
Snyk’s default model answers the first.
Merge queue requires the second.
🧪 Why Snyk can’t just “reuse” the PR result
Because the merge queue is testing:
main + PR1 + PR2 + PR3
That is a different dependency graph.
New vulnerabilities can appear due to:
version conflicts
transitive dependencies
lockfile changes
combined upgrades
PR-level validation is not enough.
🛠️ The fix (what actually works)
Run Snyk in CI instead
Use the CLI:
snyk test
And trigger it on both:
on:
pull_request:
merge_group:
✅ Make the CI job the required check
Instead of requiring:
“Snyk Security” (GitHub App)
Require:
“Snyk Scan (CI)”
This ensures:
it runs on PR (fast feedback)
it runs on merge queue (true gating)
Alternative (but risky) workaround
Some teams:
fake-pass Snyk on
merge_groupor remove it from required checks
This avoids blocking
but removes real protection
You’re effectively saying:
“We trust PR validation even though we’re using a system designed to prove that’s not enough.”
📅 Will Snyk support merge queues?
As of now:
❌ No official support for
merge_group❌ No public timeline
❌ No documentation indicating imminent support
This is part of a broader ecosystem lag - many tools still assume PR-only workflows
Merge queues expose a hidden assumption in most pipelines:
that PR validation is enough.
It isn’t.
And Snyk github integration, as currently implemented, makes that gap visible.