Run each scanner at the earliest stage where it has the input it needs. Secrets and SAST can run in the editor or on commit, SCA and IaC in pull requests, container scans at build and in the registry, and CSPM continuously against the live cloud account. Earlier is cheaper, but later stages catch what earlier ones cannot.
Stage by stage
Editor and pre-commit. SAST can run in the IDE, as OWASP notes, so a developer sees a warning while writing. Secrets checks fit here too, because the cheapest leak is the one never committed.
Push. This is where push protection acts, blocking credentials before they reach the repository. See push protection vs scanning after the fact.
Pull request. The right place for SCA, IaC scanning and diff based SAST. The author is in context, a reviewer can see the result, and a gate can block merge on critical items.
Build. Build the image, then scan it. At this stage the scanner has the real artifact, including OS packages that no manifest listed.
Registry and artifact store. Rescan stored images on a schedule. New advisories arrive after the build, so an image that passed last month can fail today.
Deploy. Admission checks can verify policy, such as only scanned images or no privileged pods.
Running environment. CSPM watches live configuration for drift. Runtime monitoring watches behaviour, which is a different tool class.
Why not everything everywhere
Every scanner at every stage multiplies alerts and slows builds. Choose one primary stage per class and a second only when it covers a different risk. For example, scan dependencies in the pull request and again on a schedule, since the second run catches new advisories on unchanged code.
Speed budget
Developers tolerate a few minutes in a pull request. If a scan takes longer, run it in parallel, scan only changed paths, or move it to a nightly job and report in a dashboard.
Blocking versus informing
Block on a small, trusted set, for example critical vulnerabilities with a fix available and any detected credential. Inform on the rest. Promote a rule from inform to block only after a trial period.
Where Safeguard fits
Safeguard provides policies and gates that can enforce checks on pull requests and deployments, alongside dependency scanning, so a rule can move from reporting to blocking when you choose.
Quick check
Why rescan something that already passed?
The code is unchanged but the vulnerability data is not. New advisories can match components already in use.
Which scanner belongs closest to the developer?
Secrets checks and SAST, because they can run in the editor or at commit.
Sources
Last reviewed: 19 October 2026.
