You usually need both. A build time scan checks code and dependencies before release and can block a bad change. A deployed estate scan checks what is actually running and catches new advisories against old releases. Build time answers "should this ship", and deployed scanning answers "what is exposed today".
Two moments, two questions
Build time scan: runs in the pipeline against the source and the built artifact.
Deployed scan: runs against what is live, or against the inventory of what is live, and re-evaluates it as new advisories appear.
A service can pass its build scan on Monday and be vulnerable on Friday, because an advisory was published in between. Nothing in the code changed. Only the knowledge about it did.
Comparison
| Aspect | Build time | Deployed |
|---|---|---|
| Question | Should this release ship? | What is exposed now? |
| Catches new advisories on old releases | No | Yes |
| Can block a change | Yes | Not directly |
| Sees manual or out of band deploys | No | Yes |
| Sees every account and site | Only pipelines you control | Anything you can inventory |
What each misses
Build time misses anything that did not pass through the pipeline: hand deployed images, forgotten functions, vendor appliances. Deployed scanning misses issues that never get a chance to appear in inventory because the artifact was blocked, which is fine, that is a win for the build gate.
How to combine them
- Gate on build. Fail the pipeline for the findings your policy treats as blocking, such as known exploited components.
- Record the artifact. Save the component list and digest at build time. That record is what the deployed side compares against.
- Re-check on a schedule. Re-evaluate every recorded artifact against fresh advisory data, so you learn about new findings without a rebuild.
- Reconcile with runtime. List what runs, and match it to recorded artifacts. Mismatches reveal deployments outside the pipeline.
- Route by owner. Findings from both sides land in the same queue per team.
The hybrid angle
In a mixed estate, some workloads never touch your main pipeline. That is the strongest argument for the deployed side. Without it, your coverage equals your pipeline coverage.
Try it yourself
Open the demo and look at how monitoring keeps checking after the first scan.
Click through it at your own pace, or open it full screen.
An example week
Monday: a build passes its scan and ships. Wednesday: a new advisory is published for a library in that release. The build gate has nothing to say, because no build is running. The scheduled re-check against recorded artifacts flags the service on Thursday morning, and the owner gets a ticket. Without the deployed side, the first signal would have been the next build, which might be weeks away.
Quick check
If my pipeline scans every build, do I still need more?
Yes, for new advisories against released code, and for anything deployed outside the pipeline.
Does deployed scanning need agents on every host?
Not necessarily. Component data from builds, registries and runtime listings can cover much of it. What you need depends on the workloads.
Safeguard offers dependency scanning, policy gates for pull requests and continuous monitoring, so both moments can be covered. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
