Scan at more than one point, because each point answers a different question. Pull request scans give fast feedback, build scans check the artifact, registry scans catch drift, and a deploy check confirms that what ships has a passing record. For release evidence, the build and deploy points matter most.
What each stage tells you
| Stage | Question it answers | Strength | Weakness |
|---|---|---|---|
| Pull request | Does this change add risk? | Fast, close to the author | Misses base image and build output |
| Build | What is in the artifact? | Matches what you will ship | Result ages after the build |
| Registry | Is a stored artifact still clean? | Catches new advisories | Not tied to a release decision |
| Deploy | May this exact artifact go live? | Enforces the gate | Late, so failures cost more |
| Runtime | What is actually running? | Reality check | Reactive |
No single point does everything. Teams that scan only at deploy find problems when changing them is most expensive. Teams that scan only at pull request miss what the base image adds.
What counts as release evidence
For an auditor tracing a release, the most useful record is the build scan tied to the artifact digest plus the deploy decision that references it. A pull request scan shows diligence during development but does not describe the shipped artifact. A registry scan shows ongoing care but is not a release decision.
NIST SSDF practice PW.4.4 says to verify that third-party components comply with the organization's requirements throughout their life cycles, and its examples include building automatic detection of known vulnerabilities into the toolchain. Throughout the life cycle implies more than one scan point.
A workable layout
- Pull request: dependency and code checks, warn or block on new high risk findings.
- Build: full artifact scan and SBOM generation, result stored against the digest.
- Registry: scheduled rescans of stored images.
- Deploy: admission or pipeline check that the digest has a passing, recent record.
- Runtime: monitoring that feeds back into rescans.
Keep the rules consistent
Use the same policy at each point, with different strictness if you want. If the pull request gate and the deploy gate disagree on what counts as a blocker, developers lose trust in both.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow a finding from detection through to remediation and notice where in the flow it first appeared.
Safeguard can scan at pull request and across repositories with policies and gates, and a free scan is at gold.safeguard.sh/scan.
Quick check
Is a pull request scan enough for a regulated release?
Rarely. It does not describe the final artifact. Add a build scan tied to the digest.
Do we need runtime scanning too?
It helps confirm what runs matches what you approved, and feeds rescans.
Sources
Last reviewed: 19 October 2026.
