Build-time controls inspect what you are making, such as dependency scans and signing. Deploy-time controls decide whether an artifact may start, such as admission policies and approvals. Run-time controls observe and limit what is already running. Each catches different mistakes, and none replaces the others.
Definitions
Build-time means checks in the editor, pull request and pipeline, before an artifact exists in its final form. Deploy-time means checks at the moment of release or admission, when the artifact is about to start. Run-time means controls and monitoring while the software is live.
Kubernetes makes the middle layer concrete. Its documentation describes admission as a step that applies to requests that create, delete or modify objects, with validating and mutating controllers. That is deploy-time: a decision on a change request, not on a running process.
A comparison
| Question | Build-time | Deploy-time | Run-time |
|---|---|---|---|
| What does it see? | Source, dependencies, build output | The manifest, the image reference, signatures, approvals | Live behavior, traffic, configuration over time |
| Typical examples | Dependency scan, SBOM, static analysis, signing | Admission policy, deploy approval, provenance check | Network policy, resource limits, audit logs, monitoring |
| Strongest at catching | Known vulnerable components, unsafe code | Unapproved sources, unsigned artifacts, risky settings | Drift, misuse, new advisories on old releases |
| Weak spot | Cannot see how it will be configured | Cannot see what happens after start | Late, so mistakes have already shipped |
| Feedback speed | Fast, in the developer workflow | Fast at release, slower to trace back | Depends on how alerts are routed |
Why you need more than one
A clean build scan says nothing about a manifest that runs a container as privileged. An admission policy says nothing about a library disclosed as vulnerable next month. A monitor tells you after the fact. The sensible approach is to put each check where its information is clearest and its cost of failure is lowest.
An example walk through
Take a new service.
- Build: dependency and SBOM scanning flag a vulnerable library, and the pull request is held until it is upgraded.
- Deploy: an admission policy checks that the image comes from an approved registry and that the pod does not request extra privileges.
- Run: network policy limits connections, audit logs record changes, and monitoring tells you when a new advisory affects the deployed version.
Remove any step and a specific mistake gets through.
How to decide where a new rule belongs
- If the data is in the code or dependency list, check at build time.
- If the data is in the deployment request, check at deploy time.
- If the data only exists once it is live, monitor at run time.
- If a mistake is hard to reverse, check earlier and make the check blocking.
What this post does not claim
Run-time controls here means things like network policy, limits and logging in your own platform. It does not mean any particular product category. Choose tools by the specific question you need answered.
Where Safeguard fits
Safeguard works mostly on the build and release side: SBOM and dependency scanning, reachability analysis, and policies, gates and guardrails, plus continuous monitoring of findings after release. Your platform's admission and network controls cover the rest.
Try it yourself
Click through it at your own pace, or open it full screen. See what a gate checks before a change moves to the next stage.
Quick check
Is deploy-time the same as runtime?
No. Deploy-time decides whether something may start. Run-time watches and limits it once it is live.
If I scan at build time, do I still need admission policy?
Yes. A scan does not see manifest settings or where an image is pulled from.
Why monitor after release?
New advisories are published about software you already shipped, and only monitoring tells you.
Sources
Last reviewed: 19 October 2026.
