Run fast, narrow checks early and slow, broad ones later. Secret and dependency checks suit the pull request. Static analysis fits the pull request or nightly build. Container and dynamic tests need a built artifact or a running app, so they sit after the build. Monitoring continues after release.
The principle
NIST's SSDF says to choose code review, analysis and testing methods based on the stage of the software. That is the whole idea: match the test to what exists at that moment.
Stage table
| Stage | What exists | Suitable checks |
|---|---|---|
| In the editor | Code being typed | IDE static analysis, secret detection |
| Commit or push | A diff | Secret scan, lint rules |
| Pull request | Diff plus dependency changes | Dependency scan, static analysis on changed files, policy gate |
| Build | Compiled artifact, container image | Full static scan, image scan, SBOM generation |
| Staging | Running app | Dynamic scan, API tests, fuzzing of parsers |
| Production | Live traffic | Continuous dependency monitoring, runtime protection where used |
Why not run everything everywhere
Time is the limit. A developer waiting twenty minutes on a check will learn to ignore it. Keep the pull request path quick and move deep work to scheduled jobs. OWASP notes that static analysis scales and can run repeatedly in nightly builds or CI, which supports splitting quick and full runs.
Gate or advise
Not every check should block. A reasonable start:
- Block on new secrets and on newly introduced critical issues that are reachable.
- Warn on medium findings and open tickets.
- Report only, no block, for new tools in their first month.
- Review the rules monthly and tighten as noise falls.
Common mistakes
The common mistake is putting every tool at the pull request and then watching build times double. Developers route around slow gates. The opposite mistake is leaving heavy tests out of the pipeline completely because they are inconvenient. Schedule them. Also decide in advance who sees each result: a pull request comment goes to the author, a nightly report goes to the owning team, and a monitoring alert goes to whoever is on call for the service.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what a pull request gate checks and what causes it to fail.
Where Safeguard fits
Safeguard offers pull request policy gates, SBOM and dependency scanning and reachability analysis. The free scan is a quick way to see the dependency view.
Quick check
Should every pull request run a dynamic scan?
Usually not. Dynamic tests need a deployed app and take longer. Run them on staging builds or a schedule.
Where do dependency checks go?
Both at the pull request, when a dependency changes, and continuously, because new advisories appear for packages you already ship.
Sources
Last reviewed: 19 October 2026.
