The Kubernetes documentation, drawing on the CNCF cloud native security white paper, describes four lifecycle phases: develop, distribute, deploy and runtime. Each has its own controls. Developers mostly own develop and distribute, share deploy with platform teams, and depend on the platform for runtime.
Phase by phase
| Phase | Goal in one line | Examples from the Kubernetes docs |
|---|---|---|
| Develop | Secure the dev environment and design the app with security in mind | Zero trust style architecture, code review that considers security, a threat model with trust boundaries |
| Distribute | Secure the supply chain for images and the components that run them | Scan images and artifacts, encrypted distribution with a chain of trust, update dependencies when advisories land, private registry |
| Deploy | Limit what can be deployed, by whom and where | Verify image identity, separate apps by namespace, enforce restrictions at admission |
| Runtime | Protect access, compute and storage while the app runs | ServiceAccounts, TLS for API traffic, Pod Security Standards, resource quotas, encryption at rest, network policy |
The docs also include a note on observability: logs and metrics generated by your containers need protection, and the whole chain that feeds a dashboard should resist failure and tampering because you will rely on it during an incident.
What this means for a developer
Develop. You decide trust boundaries before you write code. Ask who can call each endpoint, what data crosses each boundary and what happens if a dependency is hostile. A short threat model per service is enough to start. Include fuzzing or similar automation where it is justified.
Distribute. This is where most developer controls live. Scan what you build, keep dependencies current, pull from a private registry you trust, and make sure you can verify where an image came from. A dependency scan with an SBOM lets you answer "are we affected" quickly when a new advisory appears.
Deploy. Ask for admission rules that reject images that are not from your registry, pods that run privileged, and workloads in the wrong namespace. Namespaces and containers provide isolation relevant to security, but namespaces alone are not a hard boundary; see why namespaces are not a security boundary.
Runtime. You use the platform's identity and policy features: a service account per workload, minimal privileges, default deny network policy, resource limits and logging that excludes secrets.
A starting checklist for one service
- Draw the data flow and mark trust boundaries.
- Add dependency and image scanning to CI.
- Generate an SBOM per release.
- Pull only from the private registry.
- Agree admission policies with the platform team.
- Give the workload its own service account and a default deny network policy.
- Decide what is logged and what must never be.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the vulnerability workflow and note where findings from the distribute phase get triaged and assigned.
Quick check
Is this the same as the 4Cs model?
Some guides use a four C model of cloud, cluster, container and code. The current Kubernetes security overview page is organized by lifecycle phase, so this post follows that page.
Which phase should a small team start with?
Distribute. Scanning dependencies and images in CI is cheap and catches known issues before they ship.
Does Kubernetes handle runtime security for me?
It provides building blocks such as service accounts, Pod Security Standards and network policy, but you must configure and enforce them.
Where Safeguard fits
Safeguard scans dependencies and builds SBOMs, and its reachability analysis helps you separate vulnerable packages your code actually calls from those it does not. You can try a free scan at gold.safeguard.sh/scan. Policies and gates add the deploy-phase decision of what may ship.
Sources
Last reviewed: 19 October 2026.
