A cloud native security platform rests on a few tenets from the CNCF Cloud Native Security Whitepaper: security built into every lifecycle phase (develop, distribute, deploy, runtime), protection that follows workloads rather than network addresses, least privilege at every layer, secure defaults, and a supply chain you can verify. Tools matter less than whether these hold.
What is different about cloud native security?
The CNCF paper (version 2, from the Technical Advisory Group for Security) says cloud native workloads are dynamic, so identifying them by network address in a perimeter model is impractical. Security has to move closer to the workload, identified by attributes and metadata such as labels and tags, and it has to scale with constant change. That calls for more automation of controls in the lifecycle and for secure-by-design architectures such as zero trust.
It also changes who does the work. The paper says security should be injected throughout the lifecycle rather than book-ending it with separately managed interventions, and that findings should reach developers through the tools they already use, handled like a failed build.
What happens in each lifecycle phase?
The paper models the lifecycle as four phases:
- Develop. Security testing finds compliance violations and misconfigurations early, with short feedback loops. Failures follow the same workflow as other pipeline failures and must be fixed before software moves on.
- Distribute. Supply chain safety matters most here. Verify the workload and the process that built it. Artifacts such as container images need continual automated scanning for vulnerabilities and malware, and should be cryptographically signed. Immutable image binaries and URLs help.
- Deploy. Signed artifacts are verified, image and runtime policies are enforced, and host trustworthiness can be checked by binary authorization policy. The paper calls deploy-time checks the last chance to validate and enforce before the workload runs.
- Runtime. The environment has layers: hardware, host, operating system, network, storage, container runtime and orchestration. The paper says to choose a runtime isolation level that matches the workload: for example, a VM-based sandbox for an untrusted workload in a multi-tenant environment, or confidential containers for privacy-sensitive processing.
Which principles run through all phases?
- Secure defaults. The paper lists eight guidelines, including making security a design requirement, making secure configuration the easiest path, making an insecure choice a conscious decision, inheriting defaults, and giving exception lists first-class support.
- Least privilege at every layer, not only on accounts. The paper notes many containers are privileged by default or need root, and recommends rootless services and containers so an attacker who lands in one cannot easily move to the host or other containers. Mandatory access control can limit privileges further.
- Clear roles. Developers take on more security tasks, but the paper says they do not set policy, and separation of duties should stay in place between roles.
- Supply chain security. Source code, third-party code, build pipelines, artifacts and deployments each need an authenticated, trusted party and cryptographic verification where possible. The paper calls software bills of materials a critical first step to find what you have and match it to vulnerabilities.
A constructed example
A team ships a payments service. In develop, the pipeline fails on a configuration that runs the container as root. In distribute, the image is scanned, found to contain an outdated library, rebuilt and signed. At deploy, the cluster admits only signed images and rejects a hand-built test image someone tried to run. At runtime, the service uses a read-only file system and a narrow network policy, so a compromised dependency cannot reach the internal admin API. No single product did all of that. Each phase had a control, and each failure was visible to developers.
What should you ask of any platform?
Ask which phase each capability covers, whether it blocks or only reports, and whether findings land where developers work. Ask how it identifies workloads (labels and identities, not just addresses), and what it records for provenance. Be wary of coverage claims that are really one phase repeated: scanning in a registry is not the same as enforcement at admission.
How to check or apply this
- Draw your pipeline as the four phases and mark which controls exist in each and which are only advisory.
- Generate an SBOM for each deployable artifact and keep it with the image.
- Sign artifacts and enforce signature checks at deploy time.
- Run workloads as non-root with read-only file systems where possible, and set network policies by workload identity.
- Define secure defaults for new services, with an explicit exception process.
- Send findings to the developer's normal tools and measure time to fix.
Safeguard covers part of the develop and distribute phases: dependency and SBOM scanning, reachability analysis to rank findings, and policies and gates that can stop a risky change. It is not a runtime or cluster security product.
Quick check
Why not rely on a network perimeter for cloud native workloads?
Workloads are ephemeral and scale constantly, so network addresses change. The CNCF paper says protection should follow workloads, identified by attributes such as labels.
Where is the last chance to enforce a check before a workload runs?
At deploy. The CNCF whitepaper describes deploy-time checks, such as verifying signed artifacts and enforcing policy, as the last chance to validate and correct.
Sources
Last reviewed: 18 October 2026.
