Home / Knowledge hub / Pull request security check
Knowledge hub
Pull request security check
Automatic security testing that runs on a code change before it is merged.
What it means
A pull request security check is an automated test that runs on a proposed code change before it joins the main branch. It might scan the diff for known bad patterns, look for committed secrets, or check new dependencies. The result appears next to the change, so the author sees it while the code is fresh.
The point is timing. A flaw found in review costs a few minutes to fix. The same flaw found after release costs an incident, a hotfix and a conversation with customers. The check moves the first security look to the moment a developer is already looking at the code.
Why it matters
Most flaws arrive one change at a time. A new endpoint without an ownership check, a debug flag, a library upgrade that pulls in something old. If nothing looks at changes as they land, the first reader is an attacker or a yearly auditor, and by then the code is buried under months of later work.
A check that blocks the merge also turns a policy into a habit. Auditors asking how you stop vulnerable code reaching production get a clear answer: the change cannot merge until the check passes. This is the practical form of shifting security left.
How it shows up
You meet it as a status check on GitHub, GitLab or Bitbucket, usually run by your CI/CD pipeline. Typical jobs are static analysis, secret scanning and dependency review. Branch protection rules then decide whether a failing check stops the merge or only warns.
The mistakes repeat. The check is so noisy that people learn to click past it. It is set to warn only, forever. It scans the changed lines but never sees how the running app behaves, so logic flaws pass. Keep it fast, keep the failures real, and back it with testing of the deployed build.
Questions people ask
Pull request security check, answered
Does a pull request check replace a penetration test?
No. It reads code changes and matches patterns. It does not run the application, so it cannot see how two features combine or whether one signed-in account can reach another's data.
Use it as the first filter. A pentest of the running app covers what a diff cannot show.
Should a failing security check block the merge?
For high-confidence findings such as a committed secret or a known critical vulnerability, yes. A blocking check is the only version that changes behaviour.
For noisy or low-severity results, report without blocking, and tighten the rules as your team trusts them.
What should a pull request security check look for?
Start with committed secrets, injection patterns, new dependencies with known vulnerabilities and changes to authentication or access rules. These are common and well understood.
Add more only when you can keep the false positive rate low enough that people still read the results.
Can it slow developers down?
It can, if it takes twenty minutes or reports things nobody will fix. Aim for a few minutes and results the author can act on without asking security.
Run heavier tests, such as a full scan of the running app, on a schedule or at release instead.
How is this different from a code review?
A reviewer reads for design and intent and may miss a subtle pattern. A check is consistent and tireless but has no judgement. Each catches what the other misses.
Many teams also make security-sensitive paths require a named reviewer through a code owners file.
Sources
Where this comes from
Related
Terms that sit next to this one
Secret scanning
Searching code and history for keys, passwords and tokens that should not be there.
SAST
Tools that read your source code without ever running it.
Shift left
Doing security work while code is written, not as a check at the end.
Gating a build
Stopping a release automatically when a security check fails.
Code owners
People named as required reviewers for sensitive parts of a codebase.
Does the merged build still hold up?
A diff check sees the code, not the running app. We can run on a schedule or in CI/CD, gate a build, and report only what we actually exploited. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.