On every pull request, run fast checks scoped to the change: dependency changes and code analysis. At release, run the slower checks that need a built artifact or a running system, such as container image scans and dynamic tests. The split keeps feedback quick without dropping coverage.
The principle
Match the cost of a check to how often it runs. A check that takes thirty seconds can run on every change. A check that needs a built image, a deployed environment, and ten minutes belongs at a less frequent point.
If the slow checks sit on every pull request, developers wait, then work around them. If the fast checks only run at release, problems arrive late and are expensive to fix.
A practical split
| Check | Pull request | Release | Why |
|---|---|---|---|
| Dependency vulnerabilities for changed manifests | Yes | Yes | Fast, tied to the change |
| Static code analysis on changed files | Yes | Full run | Scoped is quick, full is thorough |
| License policy | Yes | Yes | Cheap |
| Container image scan | Optional | Yes | Needs a built image |
| Dynamic web or API tests | No | Yes | Needs a running environment |
| SBOM generation | Optional | Yes | Record of what shipped |
"Optional" means do it on the pull request when the image build is already part of that pipeline and takes little extra time.
Scoping to the change
Many tools can report only findings introduced by the change. Use that mode for pull requests. It keeps results short and ties each finding to the author. Run the full mode on a schedule or at release for the complete view.
Release is a different job
A release scan is less about the author and more about the artifact. It asks: what exactly are we shipping, and does it meet the bar? Save the output with the version, because it is the record you will want if a question comes up later.
Steps
- List your checks and note the runtime of each.
- Put anything under about a minute on the pull request.
- Put anything that needs a build artifact or running app at release.
- Make the pull request checks required and the release checks a gate for tier 1 services.
- Review the split twice a year as tools get faster.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that the scan works on a built image, which is why it usually sits at release or late in the pipeline.
Where Safeguard fits
Safeguard covers dependency and SBOM scanning, and pull request gates, so the quick checks and the release record can use the same policies. Try it at https://gold.safeguard.sh/scan.
Quick check
Should dynamic tests run on every pull request?
Usually not. They need a running environment and take longer. Run them on a schedule or at release unless your pipeline makes preview environments cheap.
Do pull request scans replace a release scan?
No. The release scan covers the built artifact and the state of advisories at that moment.
Last reviewed: 19 October 2026.
