Secure cloud native applications by protecting each thing they are built from and run on: container images, registries, the orchestrator, the host, and the service-to-service traffic between microservices. Add identity, secrets handling and monitoring that fit ephemeral workloads. NIST publishes guidance for both containers and microservices.
What makes cloud native different?
Cloud native applications are built as many small services, packaged as containers and run by an orchestrator that starts, stops and moves them automatically. Instances live for minutes, addresses change, and configuration is code.
OWASP's threat modeling guidance notes that classic techniques need adaptation for these systems because of shared responsibility, managed services and APIs, multi-tenant and federated identity, and dynamic infrastructure such as infrastructure as code, serverless and containers. In short: the thing you defend moves.
Where are the risk areas?
NIST SP 800-190, the Application Container Security Guide, explains the security concerns of containers, which it describes as a form of operating system virtualization combined with application packaging, and recommends ways to address them. It groups the risks by component: images, registries, orchestrators, containers and the host operating system.
A constructed example, following one change through the chain: a developer bumps a base image to pick up a library fix.
- Image. The new image still contains an old vulnerable package and an embedded test credential. An image scan at build time catches both, if you run one and fail the build.
- Registry. The image is pushed to a registry that anyone in the company can write to. Anyone could replace it. Registry access and image signing narrow that.
- Orchestrator. The deployment asks for a privileged container and a broad service account. Admission policy should refuse it.
- Container. At runtime, the process writes to the filesystem and opens odd outbound connections. Runtime monitoring would show it.
- Host. A shared node runs workloads of different sensitivity. Node isolation and a minimal host OS reduce spread.
Each layer has a different owner in most companies, which is why gaps occur between them.
What about the traffic between services?
NIST SP 800-204 addresses security strategies for microservices-based applications. It points out that the distributed, cross-domain nature of microservices needs token services, key management and encryption for authentication and authorization, plus secure communication protocols and secure service discovery. It also names resilience techniques such as load balancing, circuit breaking and throttling, and continuous monitoring. It identifies the service mesh as a well known approach for specifying these requirements uniformly.
In practice, that means mutual authentication between services, authorization rules per service pair, and encryption in transit inside the cluster, not just at the edge. NIST's zero trust architecture publication, SP 800-207, supports the same stance: no implicit trust based on network location.
What is the software supply chain angle?
Everything in the image came from somewhere: base image, operating system packages, language libraries and build tools. A software bill of materials per image, kept with the image, lets you answer "are we running the affected library?" in minutes. Dependency scanning on pull requests and image scanning in the pipeline find known issues early. Safeguard's SBOM and dependency scanning cover that part, and reachability analysis helps decide which findings matter.
How do you handle secrets and identity?
Ephemeral workloads need credentials too, and long lived keys baked into images or environment files are a common leak. Prefer short lived tokens issued to a workload identity, mount secrets at runtime from a managed store, and scan repositories and images for embedded keys before they ship. Give each service its own identity with the narrowest role that works, so a compromised pod cannot read another team's data. Rotate and revoke on a schedule you can demonstrate.
How to check or apply this
- Use minimal, pinned base images and rebuild on a schedule.
- Generate an SBOM for every image and store it with the image.
- Scan images and dependencies in CI, and block on exploited, reachable issues.
- Restrict registry write access and sign images.
- Enforce admission policy: no privileged containers, no broad service accounts.
- Use mutual TLS and per-service authorization between microservices, and monitor runtime behavior.
Quick check
Is a container a security boundary?
Containers isolate processes but share the host kernel, so they are weaker than virtual machines. Treat them as one layer of isolation, and apply host and orchestrator controls.
Where should we start?
Start with the image pipeline: scan, pin and sign. It is the cheapest control and it feeds every other layer.
Sources
- NIST SP 800-190, Application Container Security Guide
- NIST SP 800-204, Security Strategies for Microservices-based Application Systems
- NIST SP 800-207, Zero Trust Architecture
- OWASP Threat Modeling Cheat Sheet
Last reviewed: 18 October 2026.
