Cloud-native security practices in 2026 cover a substantially different attack surface than the web/cloud security disciplines that dominated through 2020. The shift to container-based deployment, Kubernetes orchestration, service-mesh communication, and increasingly autonomous CI/CD supply chains moved the security boundary from "the application" to "the platform plus the application plus the pipeline plus the runtime." Developers building cloud-native applications now operate inside a security model where the container image, the Pod spec, the network policy, the service-mesh configuration, the CI/CD attestations, and the runtime behavior detection all matter as much as the application code itself. This guide walks the cloud-native security discipline from a developer's perspective — what cloud-native security actually means, where the attack surface lives, the container image and Kubernetes-cluster patterns that matter, service-mesh and CI/CD supply-chain security, runtime detection, secrets management, and how all of this fits inside the broader application security verification work covered in the OWASP ASVS 5.0 developer guide.
What "Cloud-Native" Actually Means in 2026
Before walking the practices, the foundational question: what is cloud native security, and how does it relate to but differ from the cloud security discipline that preceded it? Cloud security focuses on the cloud provider's infrastructure layer — IAM policies, VPC configuration, security groups, encryption at rest, the broader category of "secure use of the cloud provider's capabilities." Cloud-native security extends to the application-architecture layer that sits on top — the container images that package the application, the Kubernetes orchestration that schedules them, the service mesh that mediates inter-pod communication, the CI/CD pipeline that produces them, and the runtime behavior that emerges in production. Cloud security and cloud-native security overlap but are not interchangeable; programs that conflate them tend to under-invest in the layers cloud security does not cover.
The phrase cloud-native has been overloaded enough that pinning down its meaning is now itself a meaningful exercise. The Cloud Native Computing Foundation's original definition emphasized container packaging, dynamic orchestration, and microservice orientation; the operational meaning in 2026 has expanded to include the supply-chain provenance ecosystem (SLSA, Sigstore, in-toto), the service-mesh layer (Istio, Linkerd, Cilium service mesh) and the workload identity systems that underpin it (SPIFFE/SPIRE), the runtime security toolchain (eBPF-based Falco, Tetragon, AWS GuardDuty for EKS), and the policy-as-code layer (OPA Gatekeeper, Kyverno) that mediates much of what is allowed to run inside a modern cluster.
For security purposes, the operational definition that produces the right mental model is this: a cloud-native application is one where the deployment is described as code (Dockerfile, Kubernetes manifest, Helm chart, Terraform), the runtime is mediated by an orchestrator (typically Kubernetes), the artifacts cross multiple trust boundaries between source and execution (CI builds the image, registry stores it, cluster pulls and runs it), and the network is increasingly intermediated by a service mesh that adds identity and policy enforcement at every hop. Every layer of that stack is a potential attack surface, and the defensive disciplines for each layer are different enough that treating them as a single problem misses where the bugs actually live.
The shift in mental model from monolithic-deployment security to cloud-native security is the same kind of shift that happened from on-premise to cloud security a decade earlier. The vulnerability classes did not disappear; they redistributed across the new architecture. A SQL injection still matters in a cloud-native application — but so does a misconfigured RBAC role binding that lets a low-privilege service account exec into the database pod, an unsigned container image pulled by the cluster, and a runtime privilege escalation through a container breakout. The full defensive posture has to cover all of it.
The Cloud-Native Attack Surface — Where Compromise Actually Happens
The cloud-native attack surface, walked from build to runtime, has eight layers worth distinguishing. Each layer has produced real-world breaches in 2024-2026; a complete cloud-native security program addresses all eight rather than treating the cluster as a monolith.
Source code and build dependencies. The application code itself, plus its direct and transitive dependencies. This is the layer software composition analysis addresses — the dependency tree pulled in at build time, the known CVEs against each component, and the supply-chain provenance of each dependency. Cloud-native does not change this layer fundamentally; it adds the requirement that SCA evidence flow through to subsequent layers as machine-readable SBOM artifacts.
Container image. The OCI image built from source — base image plus application binaries plus runtime dependencies. Vulnerability surface includes vulnerable base-image OS packages, vulnerable language-runtime libraries baked into the image, embedded secrets accidentally committed to the image, and misconfigured image metadata (unnecessary capabilities, root user as default, missing health checks). The defensive discipline at this layer is image scanning, distroless base images, and signed image provenance.
Registry. The container registry holding built images between build time and runtime. Attacks here include unauthorized image push (an attacker with registry credentials replaces a legitimate image), tag mutation (an attacker repoints a tag to a malicious image), and unauthenticated pull (an attacker pulls and inspects private images to learn application internals). Defenses include strict registry RBAC, immutable tags, image signature verification at pull time, and pull authentication everywhere.
Kubernetes API. The cluster's control plane — kubeapi-server, controllers, scheduler, the etcd state store. Compromise of any of these is catastrophic; an attacker with cluster-admin access has full control of every workload. The defensive layer includes RBAC scoped to the minimum necessary, audit logging of every API call, etcd encryption at rest, and the broader cluster-hardening guidance in the CIS Kubernetes Benchmark.
Pod runtime. The individual containers running inside the cluster — what they have access to (filesystem mounts, network, host namespaces, Linux capabilities), what they can talk to, and what privileges they run with. The Pod Security Standards (baseline, restricted) define configuration baselines; the kernel's security mechanisms (seccomp, AppArmor, SELinux) provide deeper isolation. Container security in detail covers the per-container hardening patterns.
Service mesh and inter-pod network. The traffic between pods. Without a service mesh, this is plain TCP/HTTP inside the cluster, mediated by Kubernetes Network Policies if they are configured. With a service mesh (Istio, Linkerd, Cilium), it is mutual-TLS-authenticated traffic with workload identity, policy enforcement, and observability. Most production clusters in 2026 run a service mesh; clusters without one have a substantially weaker inter-pod authentication posture.
CI/CD pipeline. The build infrastructure that produces images and the deployment infrastructure that pushes them to clusters. Attacks here are high-impact because the pipeline has the credentials to write to registries and the access to deploy to clusters. The defensive frame is SLSA — Supply-chain Levels for Software Artifacts — which formalizes the requirements (hermetic builds, signed attestations, verified provenance) that make pipeline compromise traceable and recoverable.
Runtime behavior. The actual process activity inside running containers. Even with every preceding layer correctly configured, a vulnerability in the application can lead to unexpected behavior (a process reading files it should not, making network connections it should not, executing binaries it should not). Runtime security tooling — Falco, Tetragon, AWS GuardDuty for EKS, commercial cloud workload protection platforms — detects these anomalies in real time and alerts or remediates.
Container Image Security — Scanning, Signing, Distroless
The container image is the cloud-native unit of deployment, and its security posture is shaped at three distinct moments: when it is built (what gets included), when it is scanned and signed (what vulnerabilities it carries and who attests to it), and when it is pulled (whether the cluster trusts it). Each moment has its own defensive discipline.
Build-time hardening. The Dockerfile or Containerfile is where most container-image security decisions are locked in. The patterns that produce hardened images: use a minimal base image (distroless from Google, Wolfi from Chainguard, Alpine if libc compatibility allows), run as a non-root user by default, drop all Linux capabilities and add back only the ones needed, omit shells and package managers from the final image (multi-stage builds with a final stage that copies only the compiled artifact), and pin every layer to a digest rather than a mutable tag. A Dockerfile that FROM ubuntu and RUN apt-get install as root is producing an image with hundreds of unnecessary packages, dozens of OS CVEs that will be flagged in scanning, and a runtime privilege baseline that is substantially worse than necessary.
Image scanning. The image is scanned for known CVEs against its dependencies — both the OS-level packages from the base image and the application-level libraries the application bundles. The tooling in 2026 is essentially standardized around Trivy, Grype, Snyk Container, and Anchore as the dominant scanners; cloud-provider native scanners (ECR scanning on AWS, ACR scanning on Azure, Artifact Registry scanning on GCP) are also widely used. The output is a vulnerability inventory tied to an SBOM (Software Bill of Materials) in SPDX or CycloneDX format, which becomes the input to downstream policy decisions about whether the image is allowed to deploy.
The integration pattern that works in practice has scanning at two stages: at build time (in CI, with results gating the build), and at registry-push time (the registry scans the image again before accepting it). Build-time scanning catches issues before the image exists in shared infrastructure; registry-time scanning catches issues that snuck past build-time scanning when scanning rules were updated after the image was originally built but before it was deployed. Production clusters should also poll the registry for vulnerability re-scans, because CVEs are discovered against already-deployed images continuously, and an image that scanned clean at build may be vulnerable a month later.
Image signing. A signed image carries cryptographic provenance that the cluster can verify before running it. The 2026 standard is Sigstore — specifically the Cosign tool and its keyless signing flow using OIDC-based identity tokens to bind signatures to a verifiable identity (a CI job, a human developer, an automated build system). The pattern: CI signs the image with Cosign at build time, the registry stores the signature alongside the image, and the cluster's admission controller (Connaisseur, Kyverno, or the cluster's native admission webhooks) verifies the signature at pull time and refuses unsigned images. Unsigned-image deployment is the cloud-native equivalent of running a downloaded binary without verifying its hash — common, but not what a hardened deployment should accept.
Distroless and minimal base images. The "less in the image, less to exploit" principle drives the move to distroless and minimal base images. A traditional Ubuntu-based application image has hundreds of packages, a full shell, package managers, system utilities — none of which the application needs at runtime, all of which contribute to the CVE inventory and the post-compromise attacker toolkit. Distroless images (Google's gcr.io/distroless/* family, Chainguard's wolfi-based images) contain only the runtime dependencies the application actually uses — typically the language runtime, the libc, and the application binary, with no shell, no package manager, no utilities. The resulting CVE inventory is substantially smaller, the attack surface after compromise is substantially smaller, and the runtime privilege baseline is substantially lower.
Kubernetes Cluster Security — RBAC, Network Policies, Pod Security Standards
The Kubernetes cluster is the orchestration layer where deployment, scheduling, and access decisions for every workload are made. Its security posture rests on three pillars: who can do what (RBAC), what can talk to what (network policies), and what each workload can do at runtime (Pod Security Standards plus security-context configuration).
Role-Based Access Control. Kubernetes RBAC defines who — which users, groups, or service accounts — can perform which verbs (get, list, create, delete) on which resource types (pods, secrets, deployments) in which namespaces. The defensive baseline is least-privilege RBAC: every workload's service account has access to exactly the resources it needs and nothing more. The anti-pattern that produces most real-world incidents is the use of the default service account in every namespace, with its default permissions, because no one took the time to define a workload-specific service account. The fix is explicit service-account-per-workload provisioning, scoped Role and RoleBinding definitions, and audit logging of every API call so privilege drift can be detected.
The advanced RBAC pattern — particularly important for multi-tenant clusters — is per-namespace isolation with no cross-namespace permissions for tenant workloads. Combined with NetworkPolicies that block cross-namespace traffic by default, this produces strong tenant isolation at the cluster level. Clusters that allow cross-namespace traffic and grant cluster-wide RBAC to tenant workloads have substantially weaker isolation, regardless of how well-configured the application security inside the namespaces is.
Network Policies. A NetworkPolicy is the Kubernetes resource that defines what traffic is allowed to and from pods. The default cluster behavior — all-allow — is the wrong default for any production cluster; the right default is deny-all with explicit allow rules for needed traffic. The pattern is: define a NetworkPolicy in each namespace that denies all ingress and egress by default, then layer specific NetworkPolicies on top that allow the actual traffic patterns needed (this pod can talk to that pod on port 5432 for database access, this pod can make outbound HTTP requests to specific external CIDRs). Network policy implementation requires a CNI plugin that enforces them (Cilium, Calico, Weave Net); clusters running CNI plugins that don't enforce network policies (vanilla Flannel, some default cloud-provider CNIs) are effectively running without network policy regardless of what their YAML says.
Pod Security Standards. The Pod Security Standards (PSS) define three profiles — privileged, baseline, restricted — that constrain what configuration a pod can use. The "restricted" profile is what production workloads should aim for: non-root user, no privilege escalation, no host namespace sharing, no privileged containers, drop-all capabilities. The "baseline" profile is slightly more permissive but still blocks the worst patterns. The "privileged" profile is for system workloads that legitimately need host access; tenant workloads should never run in privileged mode. The enforcement mechanism is the Pod Security Admission controller (built into Kubernetes 1.25+), which can be configured per namespace to enforce a specific PSS profile. Alternatives include OPA Gatekeeper and Kyverno, which provide more flexible policy expression than PSS alone.
Admission control. The admission controller is the Kubernetes mechanism that validates resources before they are stored in etcd and applied to the cluster. The cloud-native security toolchain layers admission policies for image signature verification (Connaisseur, Sigstore Policy Controller), policy-as-code constraints (OPA Gatekeeper, Kyverno), resource-quota enforcement, and pod-security-standard checks. A cluster running admission controllers as a defensive layer can refuse to apply a workload that does not meet baseline expectations — unsigned image, root user, missing resource limits, missing securityContext — before the workload ever schedules.
Service Mesh Security — mTLS, Zero-Trust Service Authentication
The service mesh layer addresses a problem traditional Kubernetes Network Policies do not: who is making this request, regardless of where in the cluster they are. Network Policies operate on IP and port; service-mesh policies operate on workload identity. The shift from network-based to identity-based authorization is the central security advantage of running a service mesh in production.
Mutual TLS by default. A service mesh in mTLS strict mode encrypts and authenticates every connection between pods, using certificates issued by the mesh's certificate authority and rotated automatically on a tight schedule (typically every 24 hours). The encryption defeats packet-capture-based attacks; the authentication ensures the receiving workload knows which workload sent the request, regardless of source IP. Istio's PeerAuthentication and DestinationRule resources, Linkerd's automatic mTLS, and Cilium service mesh's identity-based encryption are the three dominant implementations in 2026.
Workload identity. The certificates the service mesh uses bind to workload identity (the service account, the namespace, the cluster), not to IP addresses. This is the SPIFFE/SPIRE pattern — every workload has a verifiable identity issued by an identity-control-plane component (SPIRE in pure SPIFFE deployments, or Istiod for Istio mesh), and every authorization decision can reference that identity. The result is policy expression like "service A's identity can call service B's endpoints in namespace X" rather than "IP range Y can call IP range Z on port W."
Authorization policies. The service mesh expresses authorization policies as cluster resources (Istio's AuthorizationPolicy, Linkerd's Server and ServerAuthorization). The pattern: define which workload identities are allowed to call which endpoints, with the mesh's sidecar proxy enforcing the decision before the request reaches the application. The mesh layer's authorization is defense-in-depth alongside the application's own authorization — the mesh stops requests that should never have reached the application, the application enforces its own access control logic.
Service-to-service authentication for inbound external traffic. Traffic entering the cluster from outside (ingress gateways) typically authenticates differently from intra-cluster traffic. The pattern is JWT validation at the ingress gateway (the gateway verifies user-presented OIDC tokens against the identity provider's JWKS endpoint), with the gateway-verified identity propagated into the mesh as claims that downstream services can authorize against. The full federation pattern — user identity at the edge, workload identity inside, OAuth/OIDC handling the conversion — is covered in the OIDC vs SAML vs OAuth 2.0 comparison.
CI/CD Supply Chain — SLSA, Sigstore, In-Toto Attestations
The CI/CD pipeline is the cloud-native attack surface that produces every artifact running in the cluster. Compromise here scales to every workload running every signed image, because the pipeline holds the signing keys and the registry credentials. The 2026 defensive frame is built around SLSA (Supply-chain Levels for Software Artifacts), a framework that defines four progressively-stronger levels of pipeline integrity — SLSA 1 (basic provenance) through SLSA 4 (hermetic, two-person-reviewed, fully reproducible).
SLSA Level 1 — Documented Build Process. The build process produces provenance — a document describing what was built, from what source, with what build steps, by what build system. The provenance is generated automatically by the build system, not hand-written. At this level, the consumer of the artifact can verify what was built, even if they cannot verify the integrity of how it was built. The build platform is SLSA L1 compliant if it produces signed provenance for every artifact (GitHub Actions' attestation feature, Google Cloud Build, Buildkite, GitLab pipelines with attestation support all qualify).
SLSA Level 2 — Tamper-Resistance. The build runs on a hosted build platform that prevents the user from tampering with the build process. The provenance is signed with a key the user does not control. Most mature CI platforms qualify at L2 when configured correctly.
SLSA Level 3 — Hardened Builds. The build runs in an isolated, ephemeral environment. The build's inputs are explicit and verified; the build cannot reach external resources beyond what its provenance declares. This is the level most production-grade build systems aim for.
SLSA Level 4 — Audited and Reproducible. The build is reproducible (the same inputs produce bit-for-bit identical outputs), two-party-reviewed (every change is reviewed by someone other than the author), and continuously audited. Few real systems operate at L4 in practice as of 2026; it remains an aspirational target.
Sigstore. The artifact-signing ecosystem that underpins much of SLSA's verification machinery. Sigstore provides keyless signing — signatures are bound to an identity (a CI job's OIDC token, a developer's identity at a federated provider) rather than to a long-lived key the user has to manage. The signing happens against a transparency log (Rekor) that records every signature, providing public auditability. Cosign is the dominant client tool. The pattern: CI signs each artifact with Cosign at build time, records the signature in Rekor, and the verification step at deployment time checks the signature against the expected identity.
In-toto attestations. Where Sigstore signs artifacts, in-toto attestations describe the pipeline steps that produced them. An in-toto attestation is a signed statement that says "this artifact was produced by this build step, with these inputs, running this command, by this build system." A chain of in-toto attestations across pipeline steps produces an auditable trail from source to deployed artifact. The Slsa-github-generator tool produces SLSA-compliant in-toto attestations from GitHub Actions; equivalent tooling exists for most major CI platforms.
Runtime Security — eBPF, Falco, Behavioral Detection
Build-time and admission-time controls prevent unsafe configuration from entering the cluster. Runtime security covers what happens when a vulnerability in the running application produces unexpected behavior — file accesses outside the expected pattern, network connections to unexpected destinations, process executions the application should not perform. The tooling layer here is built almost entirely on eBPF (extended Berkeley Packet Filter), which provides kernel-level visibility into process activity, network activity, and file activity without requiring the application to cooperate.
Falco. The CNCF-graduated runtime security project that defines an alert language for kernel-level events. Falco rules express patterns like "a shell was executed inside a production container" or "a process inside a container made a network connection to an unexpected IP" or "a file was modified in an unexpected location." When a rule matches, Falco produces an alert that can flow into the cluster's alerting pipeline. Falco's default rule set catches many common attack patterns (container escape attempts, cryptocurrency miners, common malware behavior); production deployments typically extend it with workload-specific rules.
Tetragon. Cilium's runtime security project, which uses eBPF to provide both observability and active enforcement. Where Falco alerts on anomalies, Tetragon can also block them — terminating processes that violate policy, blocking network connections, restricting file access. The trade-off is operational complexity: enforcement at runtime can break applications that have legitimate behavior that looks anomalous to the policy. Most production deployments start with observation-only mode and graduate specific rules to enforcement mode as confidence grows.
Cloud-provider runtime security. AWS GuardDuty for EKS, Azure Defender for Kubernetes, Google Security Command Center: cloud-provider-native runtime security tools that integrate with the cluster control plane and provide alerts on suspicious activity. These tools are less customizable than Falco or Tetragon but require less operational investment, and they tie into the broader cloud-provider security posture management.
Behavioral baselines. The deeper runtime security pattern is to establish what "normal" behavior looks like for each workload and alert on deviations. Tools like Datadog Cloud Workload Security, Sysdig Secure, and Aqua use a combination of static analysis (predict what a workload should do based on its image and config) and observation (record what it actually does in production) to produce per-workload baselines. Deviations from baseline trigger alerts. The accuracy of this approach depends heavily on how stable the workload's behavior is; predictable workloads produce useful baselines, highly-variable workloads produce noisy ones.
Secrets in Cloud-Native — Vault, External Secrets, Workload Identity
Cloud-native secrets management is the discipline of getting credentials, keys, and tokens to workloads at runtime without baking them into images, committing them to source, or storing them as plaintext Kubernetes Secrets (which are base64-encoded, not encrypted, in etcd by default). The four patterns that dominate in 2026.
External secrets operator pattern. A dedicated secrets store (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) holds the source of truth for secrets. The External Secrets Operator (ESO) — a Kubernetes operator — syncs values from the external store to native Kubernetes Secrets in the cluster on a defined interval. Workloads consume Kubernetes Secrets normally; the operator handles fetching and rotation. The pattern works well when the application's secret-rotation tolerance is hours-to-days rather than seconds.
Direct API integration. The workload fetches secrets directly from the external store using its own credentials (typically a workload identity issued by the cloud provider's IAM system). No Kubernetes Secrets involved; the workload reads from Vault or Secrets Manager at startup or on demand. The pattern works well for high-rotation-tolerance workloads but adds operational complexity.
Workload identity. The workload's identity is bound to a cloud-provider IAM role through a federated identity exchange — the workload's Kubernetes service account token is exchanged for cloud-provider credentials at runtime. AWS IRSA (IAM Roles for Service Accounts), GCP Workload Identity, and Azure Workload Identity all implement this pattern. The workload gets cloud-provider credentials without long-lived secrets ever existing; the credentials are issued on demand and expire automatically.
Sealed Secrets / SOPS for GitOps. For declarative-deployment patterns where secrets must live in Git (which they should not, but sometimes operationally must), Sealed Secrets (Bitnami) and SOPS (Mozilla) provide encryption-at-rest patterns where the Git-stored ciphertext can only be decrypted by the cluster. The pattern is operationally simpler than external-store integration but produces secrets that exist as ciphertext in version control history forever, with no built-in rotation. Most mature deployments graduate from this pattern to External Secrets Operator or Workload Identity as secrets-rotation tolerance decreases.
Compliance in Cloud-Native Context
The compliance frameworks that apply to cloud-native deployments are largely the same that apply to traditional cloud deployments — SOC 2, ISO 27001, PCI DSS for payment-handling, EU CRA for products with digital elements, HIPAA for healthcare. The cloud-native-specific element is that the evidence requirements often need to extend down to the cluster, image, and pipeline layer in ways that traditional cloud evidence does not.
SOC 2 CC7.x (System Operations). The change management and vulnerability management criteria apply to cloud-native deployments with the addition that the change management evidence includes image provenance (which image is running, from what source, signed by whom) and the vulnerability management evidence includes per-workload SBOM and CVE inventories.
PCI DSS 4.0.1 Requirement 6. The secure-development and verification requirements apply with the addition of cluster-level segmentation (Network Policies isolating cardholder data environment workloads), image provenance for PCI-scoped workloads, and runtime monitoring as the operational evidence of ongoing controls. The PCI DSS 6.2.2 secure coding training guide covers the broader training-evidence requirements.
EU CRA Annex I. The CRA's vulnerability handling and security update obligations map to the cloud-native operational reality reasonably directly — image scanning produces the vulnerability inventory the CRA expects, signed updates satisfy the secure-update requirements, runtime monitoring satisfies the ongoing-security obligations. The EU CRA developer guide covers the operational mapping.
NIST 800-53 Rev. 5. The federal control set commonly applied to government-cloud deployments includes controls (SI-7 Software Integrity, CM-7 Least Functionality, AC-6 Least Privilege) that map cleanly onto cloud-native patterns — SI-7 to image signing and Sigstore, CM-7 to distroless and Pod Security Standards, AC-6 to RBAC scoping and Network Policies.
Where Cloud-Native Security Fits in ASVS and Secure SDLC
The cloud-native security patterns above slot into the broader application security verification work most teams already run. OWASP ASVS 5.0 chapter V13 Configuration covers the deployment-configuration requirements that include cluster RBAC, network policies, and pod security standards. V12 Secure Communication covers the service mesh mTLS layer. V11 Cryptography covers the signing-key management for Sigstore and the broader cluster cryptographic operations. The supply-chain elements added in ASVS 5.0 cover SBOM, image scanning, and SLSA attestation evidence.
The secure SDLC pillar covers the broader development lifecycle that cloud-native security activities embed into. Threat modeling during design covers the cluster-level attack surface alongside the application's. Verification during testing covers cluster-policy compliance alongside application functionality. Monitoring in production covers runtime security alongside application telemetry. The framework is unchanged; the specific verification activities at each phase extend to cover cloud-native concerns.
The integration point most often underinvested is the cluster-level threat model. Teams that produce thorough application-level threat models often skip the cluster-level threat modeling that would identify which workload-to-workload trust relationships exist, which service-account permissions are excessive, and which cluster admission controls would block bad configurations before they reach production. The pattern that works is per-cluster threat modeling alongside per-application threat modeling — the cluster is a security boundary worth modeling explicitly, with its own attack surface and its own defensive controls.
The 2026 Cloud-Native Security Stack — A Recommended Baseline
For an organization starting a cloud-native security program in 2026, the recommended baseline stack is: container image scanning with Trivy or Grype at build and registry-push time; image signing with Cosign and signature verification at admission time via Connaisseur or Sigstore Policy Controller; SLSA Level 2 build provenance from a hosted CI platform with attestation support; Pod Security Standards enforcement at the "restricted" profile via Pod Security Admission; deny-all default Network Policies with explicit allow rules per workload; a service mesh (Istio, Linkerd, or Cilium service mesh) with mTLS strict mode; External Secrets Operator integration with HashiCorp Vault or cloud-provider secrets management; Falco or Tetragon for runtime alerting; and SBOM generation in SPDX or CycloneDX format flowing into a vulnerability management platform.
This baseline is opinionated but defensible. Each component addresses a specific attack surface, integrates with the others, and is the dominant tool in its category as of mid-2026. Organizations adopting cloud-native security incrementally typically start with image scanning and Pod Security Standards (the easiest wins), add signature verification and Network Policies in the second phase, layer in service mesh and runtime security in the third phase, and add SLSA provenance and full supply-chain attestations in the fourth. The phasing matters because each layer's value depends on the layer below being in place — signature verification is meaningless without signed images; runtime detection is noisy without baseline-good Pod Security Standards.
The interactive code review challenges in the SecureCodingHub catalog include cloud-native scenarios covering Dockerfile hardening, Kubernetes manifest review, RBAC role binding analysis, and the broader vulnerability patterns that show up in real cloud-native incidents. The combination of policy-as-code training and per-vulnerability code review training is the program structure that most reliably produces developers who can both review the application code and review the cluster configuration that surrounds it — which is the joint discipline cloud-native security actually requires.