What does cloud native mean, and what changes for security?

Cloud native describes software built from containers, microservices and declarative APIs that run on dynamic infrastructure. For security it means the unit of defence changes from the server to the image, the identity, the configuration and the pipeline, because everything is created, replaced and scaled by automation.

How does the CNCF define it?

The Cloud Native Computing Foundation describes cloud native technologies as ones that let organisations build and run scalable applications in modern, dynamic environments such as public, private and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure and declarative APIs are named as examples. The definition adds that these techniques make loosely coupled systems resilient, manageable and observable.

Note what is missing: the definition does not require any particular vendor or cloud. It describes a style of building.

Why does the old model stop working?

In a classic data centre a server lives for years. You harden it, patch it and watch it. In a cluster, a container may live for minutes and be replaced from an image. Patching a running container is the wrong move, since the next deployment brings the old image back.

Network location also means less. Services find each other by name, traffic moves between many small components, and the perimeter is hard to draw. Identity and policy carry more weight.

Where does risk concentrate?

Images. Every image carries an operating system layer and dependencies. A vulnerability in a base image reaches every service built from it. Rebuild from updated bases and track what each image contains.

Configuration. Cluster and cloud settings are code: manifests, templates, policies. A single permissive role or public storage setting can undo careful application work. Review them like source.

Identity. Workloads, pipelines and people all need credentials. Short-lived, narrowly scoped credentials beat long-lived keys in environment variables.

Pipelines. The system that builds and deploys has the power to change production. Protect it the way you protect production.

Shared responsibility. The cloud provider secures its platform. You secure what you put on it. Know where that line sits for each service you use.

A constructed example

A team runs fifteen services on Kubernetes. A scan of their registry finds that eleven images share one base with a vulnerable library. The vulnerable function is called in only two services.

Old thinking: patch fifteen services. Cloud native thinking: update the base image once, rebuild everything through the pipeline, and prioritise the two services where the code path is reachable. The deploy is routine because the pipeline already exists. They also add a policy that blocks images older than thirty days from reaching production.

What practices fit this model?

• Build minimal images and pin versions by digest.
• Scan images and dependencies in CI, and generate an SBOM for each image.
• Keep infrastructure and cluster configuration in version control with review.
• Enforce policy at admission and in the pipeline, not by memo.
• Use workload identity and short-lived credentials.
• Log and trace across services so you can follow a request.

Safeguard supports this with dependency and SBOM scanning, reachability analysis and policy gates in the pipeline. It does not replace runtime or network security tooling.

What should teams stop doing?

Stop logging in to servers to fix things by hand, since changes made that way vanish at the next deployment and leave no record. Stop treating a cluster network as one trusted zone. Stop storing long-lived credentials in image layers, where they are easy to extract. Replace each habit with a pipeline step: build, scan, sign, deploy, and a reviewed configuration change when something needs to differ. The result is a system you can rebuild from source, which is also a strong position from which to recover after an incident.

How to check or apply this

1. List your base images and which services use each.
2. Add image and dependency scanning to every build.
3. Move cluster and cloud configuration into reviewed code.
4. Replace long-lived keys with short-lived credentials where you can.
5. Write one policy gate, such as no images older than a set age, and enforce it.
6. Document the shared responsibility line for each cloud service you use.

Quick check

Sources

• CNCF Cloud Native Definition, CNCF
• NIST SP 800-218, Secure Software Development Framework, NIST
• CISA Secure by Design, CISA

Last reviewed: 18 October 2026.