Cloud Security 2026 Complete Guide - Zero Trust, SBOM/SLSA, CSPM/CNAPP, Wiz, Falco, Sigstore, Vault, Tailscale, Cloudflare Deep Dive

Introduction — May 2026, Cloud Security Has Shifted to "Supply Chain + Runtime"

The XZ Utils backdoor of March 2024 (CVE-2024-3094) changed the conversation around cloud security overnight. The era of "just put a firewall in front of it" is over; what matters now is malicious code that enters at build time and anomalous behavior at runtime. As of May 2026, the market follows this trend. Wiz pivoted from a Google acquisition negotiation in mid-2025 toward a $20B IPO, Tailscale closed a Series C at a$1.4B valuation around identity-based mesh VPN, and Sigstore reached CNCF Graduated status.

This article is not a marketing matrix. It honestly maps "the seven layers of the 2026 production cloud security stack": Zero Trust Network Access (ZTNA), CSPM/CNAPP, SBOM/SLSA supply chain, runtime security, secrets/PAM, IaC/policy-as-code, and finally governance/compliance — with real configurations alongside the comparisons.

Cloud Security 2026 Stack — Seven Layers

Here is the big picture. The 2026 standard cloud security stack splits into seven layers.

1. Network / Zero Trust (ZTNA): VPN replacement, identity-based microsegmentation
2. Cloud posture management (CSPM/CNAPP): misconfigured cloud resource detection, plus container images and runtime in one pane
3. Supply chain security (SBOM/SLSA): provenance, integrity, dependency visibility of build artifacts
4. Runtime security: anomalous syscall detection at container/node level
5. Secrets / PAM / IGA: password, API key, certificate, and permission lifecycle
6. IaC + policy-as-code: guardrails at the Terraform/K8s manifest stage
7. Governance / compliance: ISMS-P, SOC 2, NIS2, GDPR, Korea PIPA, Japan APPI

The era of "one or two tools per layer" is over. A supply chain incident is not stopped by a ZTNA policy, and a runtime incident is not surfaced by a CSPM score. That is why the integrated CNAPP trend has accelerated. We go through one layer at a time below.

Zero Trust Network Access (ZTNA) — The Slow Death of the VPN

The Zero Trust idea boils down to one line: "do not trust the network location." Every request is verified against user identity, device posture, and context. As of May 2026 the market splits this way.

• Cloudflare Zero Trust (formerly Cloudflare for Teams): global edge based. The free 50-seat tier accelerated startup adoption. WARP client, Access (SaaS + self-hosted apps), Gateway (SWG), and Tunnel (reverse proxy) are packaged together.
• Tailscale: WireGuard-based mesh VPN. Identity comes from Okta/Google/Azure AD/GitHub. Code-driven ACLs (JSON), tag-based service routing. Since the 2025 Series C they have strengthened SCIM, posture checks, and key rotation.
• Zscaler: leader of the enterprise SASE market. ZIA (internet gateway) + ZPA (app access) + ZDX (digital experience). Heavy footprint at Korean and Japanese enterprises.
• Netskope: SSE/CASB integration leader. Data protection (DLP) and cloud app visibility are differentiators.
• Palo Alto Prisma Access: part of the Prisma SASE bundle. Integrates with Strata Cloud Manager.
• Twingate: frequently compared with Tailscale. Agentless side-car and private routing without an NLB.
• OpenZiti: a 100% open-source ZTNA fabric. Champion of the self-hosted camp.
• Boundary (HashiCorp): PAM-friendly ZTNA that wires directly into Vault. SSH/DB/RDP session brokering is its specialty.

The selection criteria are simple. There are three axes: global edge vs self-hosted vs mesh identity. Cloudflare is the global edge standard, Tailscale is the mesh identity standard, and OpenZiti/Boundary represent the self-hosted camp.

Tailscale ACL — Standard Example of Code-Driven Network Policy

A Tailscale ACL controls device-, user-, tag-, and port-level access in a single JSON file. A real ACL example.

{
  "tagOwners": {
    "tag:prod-db":   ["group:sre"],
    "tag:dev-web":   ["group:devs"],
    "tag:bastion":   ["group:sre"]
  },
  "groups": {
    "group:sre":  ["alice@example.com", "bob@example.com"],
    "group:devs": ["carol@example.com", "dave@example.com"]
  },
  "acls": [
    { "action": "accept", "src": ["group:sre"],  "dst": ["tag:prod-db:5432", "tag:bastion:22"] },
    { "action": "accept", "src": ["group:devs"], "dst": ["tag:dev-web:80,443"] }
  ],
  "ssh": [
    { "action": "accept", "src": ["group:sre"], "dst": ["tag:bastion"], "users": ["root", "ubuntu"] }
  ],
  "nodeAttrs": [
    { "target": ["group:sre"], "attr": ["funnel"] }
  ]
}

The value of this ACL is that it is a network policy that can be reviewed in a PR. Push to Git, review on Slack on change, and it applies when merged. The "Excel-sheet-based change management" of traditional firewall rules is no longer an acceptable answer.

From CSPM to CNAPP — The Integration War of Wiz, Orca, and Prisma Cloud

CSPM (Cloud Security Posture Management) originally meant "find the misconfigured S3 bucket." In 2026 that role shifted to CNAPP (Cloud-Native Application Protection Platform): a single platform that covers IaC scanning, build, registry, runtime, and data in one pipeline.

• Wiz: founded 2020, valued above $20B in 2025. Agentless scanning is the differentiator. Wiz Code (IaC), Wiz Cloud (posture), Wiz Defend (runtime) split out the lineup.
• Orca Security: SideScanning patent. Snapshot-based analysis through cloud APIs only.
• Lacework: behavior analysis based on the Polygraph. Joined the Fortinet SASE bundle after acquisition.
• Prisma Cloud (Palo Alto): a unification of the former RedLock, PureSec, Twistlock, and Bridgecrew. Largest in scale.
• Sysdig Secure: home of Falco. Runtime + CSPM bundle. Strong in the container camp.
• Aqua Security: container/Kubernetes security pioneer. Home of Trivy.
• Snyk Cloud: developer-first positioning. Bundled with Snyk Code/Open Source/Container/IaC.
• Tenable Cloud Security: from the Ermetic acquisition. CIEM (entitlement analysis) is the strength.
• Microsoft Defender for Cloud: Azure native with multicloud extensions.
• AWS Security Hub: aggregated with GuardDuty, Inspector, and Macie in one pane. Weak on multicloud.
• GCP Security Command Center: free SCC Standard and paid Premium.
• Lookout / Datadog Cloud Security: new entrants. Mobile/observability strengths.

The selection criteria are agentless vs agent-based, multicloud depth, and IaC integration. Wiz is the agentless standard, Sysdig/Aqua lead the agent-based runtime camp, and Snyk represents the developer-friendly side.

The Era of SBOM — CycloneDX and SPDX, and U.S. Executive Order 14028

SBOM (Software Bill of Materials) became a required artifact for all U.S. federal procurement software after Executive Order 14028 in 2021. NIST SP 800-218 (SSDF) was revised to 2.0 in 2024 and made the SBOM requirement more concrete, and in 2025 both EU NIS2 and the Korean ISMS-P certification supplements joined the SBOM mandate trend. Japan's METI released v2.0 of its "SBOM guidelines for OSS use" in August 2024.

There are effectively two standards.

• CycloneDX: under OWASP. Driven by the security camp. VEX (Vulnerability Exploitability eXchange) integration, SaaSBOM, and AI/ML model BOM support are differentiators.
• SPDX 3.0: under the Linux Foundation. Driven by the licensing camp. SPDX 3.0 (ISO/IEC 5962:2021) added a security profile, narrowing the gap between the two standards.

Generators have effectively consolidated into four.

• Syft (Anchore): extract SBOM from image/directory. Both CycloneDX/SPDX outputs.
• Trivy (Aqua): bundles scanning and SBOM. CycloneDX/SPDX/Trivy's own format.
• cdxgen (official CycloneDX): multi-language support. Covers SaaSBOM and Operations BOM.
• GitHub dependency-graph export: GitHub Advanced Security emits SBOM automatically.

The minimal shape of a CycloneDX JSON SBOM looks like this.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-05-16T09:00:00Z",
    "tools": [{ "vendor": "Anchore", "name": "syft", "version": "1.20.0" }],
    "component": {
      "type": "application",
      "name": "checkout-api",
      "version": "1.42.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/express@4.21.2"
    },
    {
      "type": "library",
      "name": "left-pad",
      "version": "1.3.0",
      "purl": "pkg:npm/left-pad@1.3.0"
    }
  ]
}

The value of an SBOM is simple. Can you answer the blast radius of a fresh CVE in under five minutes? During Log4Shell, XZ Utils, and the 2025 npm typosquatting wave, the gap between organizations with and without SBOMs was measured in days, not hours.

SLSA Framework and in-toto — Standard for Build Provenance

SLSA (Supply-chain Levels for Software Artifacts) is the OpenSSF-led build integrity framework. As of 2026, v1.0 is stable and v1.1 is in RC. The four levels are the core.

• SLSA L1: build process documented
• SLSA L2: hosted build + signed provenance
• SLSA L3: build isolation (non-falsifiable provenance)
• SLSA L4: hermetic, reproducible build

The most common provenance format is the in-toto attestation. Per predicate type it standardizes SLSA provenance, SBOM, Vuln, SCAI, and others. In 2025 the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) WG published its RFC drafts for SBOM/attestation transparency services, and entered WG Last Call in Q1 2026.

A standard in-toto provenance example.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/acme/checkout-api",
    "digest": { "sha256": "abc123def456..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/tags/v1.42.0",
          "repository": "https://github.com/acme/checkout-api",
          "path": ".github/workflows/release.yml"
        }
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner/v2" },
      "metadata": { "invocationId": "https://github.com/acme/checkout-api/actions/runs/12345" }
    }
  }
}

Sigstore — Signing, Transparency Log, Keyless Standard

Sigstore started in 2021 under the Linux Foundation and reached CNCF Graduated in 2024. It is composed of three components.

• cosign: CLI for signing container images, SBOMs, and blobs
• Fulcio: a keyless OIDC-based short-lived certificate authority
• Rekor: an append-only transparency log

The core idea is keyless signing. Developers do not store private keys; instead they request signing from Fulcio with an OIDC ID token (GitHub Actions, Google, Microsoft), and Fulcio issues a short-lived X.509 certificate. The signature is logged in Rekor, which uses a Merkle tree to prevent tampering.

A typical cosign flow.

# 1) Keyless sign (GitHub Actions OIDC)
cosign sign \
  --identity-token "$ACTIONS_ID_TOKEN" \
  ghcr.io/acme/checkout-api@sha256:abc123def456

# 2) Attach SBOM as an attestation
cosign attest \
  --predicate sbom.cdx.json \
  --type cyclonedx \
  ghcr.io/acme/checkout-api@sha256:abc123def456

# 3) Verify (at deploy time)
cosign verify \
  --certificate-identity "https://github.com/acme/checkout-api/.github/workflows/release.yml@refs/tags/v1.42.0" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/acme/checkout-api@sha256:abc123def456

After the XZ Utils backdoor in 2024, GitHub Actions, GitLab CI, npm, and PyPI are integrating Sigstore at a rapid pace. npm has been emitting Sigstore provenance through npm publish --provenance since 2023, and as of Q1 2026 over 60% of the top 1000 packages have provenance.

GUAC — The SBOM Graph Database

Once SBOMs and attestations are collected, the next question is "how do we query them?" Grepping SBOMs scattered across 10,000 microservices is not the answer. That is why GUAC (Graph for Understanding Artifact Composition) emerged in 2023.

• Input: SBOM (CycloneDX/SPDX), in-toto attestations, SLSA provenance, Sigstore Rekor logs
• Storage: graph DB such as Neo4j (or ArangoDB, PostgreSQL)
• Output: GraphQL API + CLI

Typical question examples.

• "Find every container image using Log4j 2.17.1 or below"
• "Find every production deploy without a Sigstore signature"
• "Find npm packages in the direct/indirect dependency tree with an average score under 1"

GUAC is heading toward v1.0 GA in May 2026, with Kusari offering a commercial managed service. Dependency-Track (OWASP) is the other major option in the SBOM indexing camp.

Trivy Image Scan — The Most Used OSS Scanner

Trivy is an OSS scanner built by Aqua Security that handles container images, filesystems, Git repositories, Kubernetes manifests, and Terraform from a single tool. As of May 2026 it has 23k GitHub stars and is effectively the standard in the Kubernetes camp.

# Image scan (CVE + license + secret + misconfigurations)
trivy image \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  --format sarif \
  --output trivy.sarif \
  ghcr.io/acme/checkout-api:v1.42.0

# SBOM generation (CycloneDX)
trivy image \
  --format cyclonedx \
  --output sbom.cdx.json \
  ghcr.io/acme/checkout-api:v1.42.0

# Terraform policy check
trivy config ./infra/terraform

# Kubernetes cluster posture
trivy k8s --report summary cluster

The alternatives are strong as well. Grype (Anchore) pairs with Syft as the standard for SBOM-first workflows, Snyk Container prioritizes developer UX, and Anchore Enterprise has the strongest policy engine. OSV-Scanner (Google) uses the OSV.dev dataset for accurate matching.

Runtime Security — Falco vs Tetragon, the Era of eBPF

Runtime security covers "anomalous behavior inside containers that are already deployed." As of May 2026 the market splits in two camps.

• Falco (CNCF Graduated): built by Sysdig, reached CNCF Graduated in January 2024. libbpf-based eBPF driver. Rule-based detection.
• Tetragon (Isovalent/Cisco): home of Cilium. eBPF + LSM hooks. Adds policy enforcement.
• KubeArmor: led by AccuKnox. LSM (AppArmor, BPF-LSM) based.
• Calico Enterprise / Calico Cloud (Tigera): combines network policy with runtime.
• Datadog Cloud Security: SaaS-first runtime security. Integrates with Datadog observability.

Falco rules are written in YAML. An example rule that catches "a shell was spawned inside a container."

- rule: Terminal Shell In Container
  desc: A shell was spawned by a container with an attached terminal.
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint and not user_expected_terminal_shell_in_container_conditions
  output: >
    A shell was spawned in a container with an attached terminal
    (user=%user.name container_id=%container.id container_name=%container.name
     shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: NOTICE
  tags: [container, shell, mitre_execution]

Tetragon writes similar policies as policy-as-code (K8s CRDs) and goes further by enforcing block actions at LSM hooks. Falco is the detection standard; Tetragon is the rising star in the detect-and-block camp.

Secrets Management — Vault, Doppler, Infisical

Secrets are one of the most common incident vectors in security. According to the 2024 GitGuardian State of Secrets Sprawl report, 12.9 million secrets were exposed on public GitHub repositories, growing to 17.4 million in 2025. The tool options are as follows.

• HashiCorp Vault: effectively the standard. Despite the BSL license change controversy after the 2024 IBM acquisition, the market share is still number one. Dynamic secrets (auto-issued DB credentials), Transit (EaaS), PKI, and KV are the core secret engines.
• OpenBao: a Linux Foundation OSS fork that responded to the Vault BSL transition. v2.0 GA in 2025.
• AWS Secrets Manager / SSM Parameter Store / GCP Secret Manager / Azure Key Vault: the cloud-native camp. Sufficient for single-cloud cases.
• Doppler: developer UX first. Began with .env file sync.
• Infisical: OSS + SaaS. The open-source alternative to Doppler.
• AKEYLESS: positions itself as KMS-as-a-Service. Distributed Fragments Cryptography (DFC) based key management.
• CyberArk Conjur: home of enterprise PAM. K8s/CI friendly OSS line.

PAM (Privileged Access Management) / IGA (Identity Governance & Administration) is a separate market.

• CyberArk: PAM number one. EPM (Endpoint Privilege Manager) bundle.
• BeyondTrust: PAM number two. Password Safe, Privileged Remote Access.
• Delinea (merger of Thycotic + Centrify): PAM number three.
• SailPoint / Saviynt / Okta: IGA + identity.

Vault Dynamic Secrets — The End of Static Secrets

The core value of Vault is "do not pre-create secrets; issue them on demand." A new PostgreSQL user/password is issued for every request and is revoked automatically when the TTL ends.

# vault server config (HCL)
storage "raft" {
  path    = "/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/tls/cert.pem"
  tls_key_file  = "/etc/vault/tls/key.pem"
}

seal "awskms" {
  region     = "ap-northeast-2"
  kms_key_id = "alias/vault-unseal"
}

api_addr     = "https://vault.internal:8200"
cluster_addr = "https://vault.internal:8201"
ui           = true

# 1) Enable DB secret engine
vault secrets enable database

# 2) Register PostgreSQL connection
vault write database/config/checkout-db \
  plugin_name=postgresql-database-plugin \
  allowed_roles="readonly,readwrite" \
  connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/checkout" \
  username="vault-admin" \
  password="$ADMIN_PW"

# 3) Define role (TTL 1 hour)
vault write database/roles/readonly \
  db_name=checkout-db \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# 4) Issue a user
vault read database/creds/readonly

The issued user is revoked automatically when the TTL ends. Even if the secret leaks to Git, a wiki, or Slack, it is invalid after one hour. That is the essence of the Zero Trust secret model.

IaC Scanning — Checkov, tfsec, KICS, Terrascan

Terraform/CloudFormation/K8s manifests are build artifacts but at the same time "code." Code can be scanned.

• Checkov (Bridgecrew → Palo Alto): the most widely used OSS. Covers Terraform, CloudFormation, K8s, ARM, Bicep, Helm, Dockerfile, and Kustomize.
• tfsec (Aqua): merged into Trivy but the standalone CLI remains.
• KICS (Checkmarx): 200+ scan rules. Multi-IaC.
• Terrascan (Tenable): OPA Rego based policy engine.
• Snyk IaC: developer-friendly. Part of the Snyk bundle.

A Checkov run is one line.

checkov -d ./infra/terraform \
  --framework terraform \
  --output sarif \
  --output-file-path checkov.sarif \
  --skip-check CKV_AWS_79

Three representative misconfiguration patterns.

• S3 bucket public-read ACL (CKV_AWS_20)
• RDS storage encryption disabled (CKV_AWS_17)
• Security group with port 22 open to 0.0.0.0/0 (CKV_AWS_24)

These three are the first, second, and third lines of nearly every incident report.

Policy-as-Code — OPA Gatekeeper, Kyverno, Conftest, Cedar

Policy-as-code is the flow where every resource entering a Kubernetes cluster is validated at the admission webhook stage.

• OPA (Open Policy Agent) + Gatekeeper: CNCF Graduated. Rego DSL.
• Kyverno: YAML based. Lower learning curve than OPA.
• Conftest: CLI that runs OPA Rego in CI/CD.
• Cedar (AWS): AWS Verified Permissions / Cedar policy language. Open sourced in 2023.

An OPA Rego policy that enforces "every deploy must have resource limits."

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresources
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResources
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredresources
        violation[{"msg": msg}] {
          container := input.review.object.spec.template.spec.containers[_]
          not container.resources.limits.cpu
          msg := sprintf("container %v missing cpu limits", [container.name])
        }
        violation[{"msg": msg}] {
          container := input.review.object.spec.template.spec.containers[_]
          not container.resources.limits.memory
          msg := sprintf("container %v missing memory limits", [container.name])
        }

The same policy in Kyverno is shorter; one YAML file is enough. "OPA is expressive, Kyverno is readable" is a well-known summary that still holds in 2026.

Secret Scanning — gitleaks, truffleHog, GitGuardian

This is the layer that finds exposed secrets in code, commits, and images.

• gitleaks: number one OSS. Friendly with pre-commit hooks and CI.
• truffleHog: OSS from the SourceAgent camp. The verified-secret classification is the differentiator.
• GitGuardian: number one SaaS. Detects 1,000+ secret types with automated blocking (Honeytoken).
• Spectral (acquired by Checkpoint): integrated SaaS for IaC + secrets + SBOM.

The operational flow is a triple of pre-commit + CI + scheduled scan (weekly full-history).

SAST/DAST and SCA — GitHub Advanced Security, Snyk, FOSSA, Mend

SAST (Static) for code itself, DAST (Dynamic) for the running app, and SCA (Software Composition Analysis) for open-source dependencies form a separate market.

• GitHub Advanced Security: CodeQL (SAST) + Dependabot (SCA) + Secret Scanning. For GitHub users it is the most natural choice.
• GitLab Dependency Scanning: part of the GitLab Ultimate bundle.
• Snyk: developer-first. Snyk Code (SAST) + Open Source (SCA) + Container + IaC.
• FOSSA: strong in license compliance. Frequently shows up in M&A due diligence.
• Mend (formerly WhiteSource): early leader in SCA. Enterprise license analysis.
• Sonatype Lifecycle / Nexus IQ: home of Maven Central. Enterprise SCA.
• Veracode / Checkmarx: enterprise SAST camp.

The 2026 trend is simple: use the tool that integrates naturally with GitHub, or use a multi-VCS tool like Snyk. One of those two.

CSPM/CNAPP Tool Matrix — As of May 2026

The practical selection criteria as a table.

The shortlist is determined by integration with the existing EDR/SIEM, multicloud depth, price, and agentless preference.

ZTNA Tool Comparison — Global Edge vs Mesh vs Self-Hosted

Same approach for ZTNA.

Cloudflare Zero Trust + Tailscale is the standard answer for SMBs in 2026. Cloudflare for external-to-internal SaaS/app access, Tailscale for internal-to-internal device/service mesh.

Korea / Japan / EU Compliance — 2026 Changes

The regulatory side is moving quickly as well.

• Korea ISMS-P: the December 2024 revision explicitly added an SBOM management item as an appendix. In force from July 2025. A new supply chain security control (2.10.1) was created.
• Korea PIPA: since the September 2023 revision came into force, pseudonymized information, portability, and the right to refuse automated decisions were added. The EU GDPR adequacy decision granted to Korea remains in effect in 2026.
• Japan APPI: the April 2024 amendment took effect. Pseudonymous/anonymous processing and reporting duties for foreign operators were strengthened. An April 2026 further amendment introduces a data broker registry.
• Japan METI SBOM guideline: v2.0 in August 2024 and v3.0 in February 2026. Manufacturing/IoT first.
• EU NIS2: in force across EU member states from October 2024. Imposes ICT supply chain security duties on "essential/important" operators across 18 industries. SBOM, 24-hour incident notification, and patch SLAs are the core.
• EU CRA (Cyber Resilience Act): entered into force in December 2024, with full application in December 2027. Mandates SBOM for any product with digital elements.
• U.S. Executive Order 14028: SBOM required for federal procurement since 2021. NIST SP 800-218 SSDF 2.0 in 2025.
• PCI DSS 4.0: minor update to v4.0.1 in March 2025. SBOM, authentication hardening, and payment-page script management (6.4.3) are the core.

Post-Quantum Cryptography (PQC) — The 2026 Starting Line

In August 2024 NIST finalized three algorithms as standards: ML-KEM (key exchange), ML-DSA (signature), and SLH-DSA (hash-based signature). The state of play in May 2026.

• Cloudflare: since 2024 applies ML-KEM-768 and the X25519-MLKEM768 hybrid KEX by default to TLS 1.3 handshakes. As of Q1 2026, 35% of traffic is on PQC hybrids.
• Google: Chrome 124 (April 2024) enables X25519MLKEM768 by default.
• AWS KMS: supports ML-DSA signatures since September 2024.
• OpenSSH: sntrup761x25519 hybrid since 9.0. Added ML-KEM in 9.9 (September 2024).

The CRA SBOM mandate and the PQC transition run in parallel between 2026 and 2028. This is why a CBOM (Cryptographic Bill of Materials) — recording "what cryptographic primitives this library uses" — was added in CycloneDX 1.6.

The 2025 npm Typosquatting Wave and the Supply Chain Threat Map

Major supply chain incidents in the npm camp during 2025.

• January 2025: seven typosquatting variants of eslint-config-prettier, with 2.3M cumulative downloads.
• April 2025: the lottie-player compromise. A password-stealing payload was injected into a legitimate package. CDN cache invalidation took 36 hours.
• June 2025: 64 typosquatting variants of colorama/requests on PyPI taken down in one sweep.
• September 2025: wallet key theft via npm packages mimicking the Solana SDK. Total damages around $800K.
• November 2025: 24 secret leakage incidents caused by misuse of pull_request_target in GitHub Actions workflows.

The standard response is simple. Lockfile + integrity hash + Sigstore verification + change-isolated build. In addition, npm announced it will default --require-provenance to on starting January 2026.

A Reference Build Pipeline — The 2026 "Safe Build" Picture

Finally a reference pipeline that combines everything.

1. PR stage: gitleaks, Snyk Code/CodeQL, Checkov, dependency review action
2. Build stage: hermetic container build, SLSA L3 builder (GitHub-hosted runner + reusable workflow)
3. Artifact stage: cosign keyless signing, SBOM attached (CycloneDX), SLSA provenance attestation
4. Registry: GHCR/ECR with immutable tags, Sigstore signing policy
5. Deploy stage: K8s admission webhook (OPA/Kyverno) rejects unsigned or provenance-less artifacts
6. Runtime stage: Falco/Tetragon rules, CSPM (Wiz/Sysdig) watching posture + drift
7. Incident response: SBOM index (GUAC/Dependency-Track) answers blast radius in under five minutes

As of May 2026 the number of organizations with all seven stages in place sits around the top 1% globally. The good news: stages 1 through 3 are achievable with OSS alone, and stages 4 through 6 mostly require one cloud-native CNAPP.

Closing — Cloud Security 2026 in One Sentence

The essence of 2026 cloud security distills to one line. "What happens inside the firewall is the scary part." The XZ Utils backdoor came in at build time, the 2025 npm typosquatting wave hid deep in the dependency tree, and no organization without an SBOM could answer their blast radius in time.

The answer is simple.

• Use Zero Trust to delete network trust
• Use CNAPP to put cloud posture on one screen
• Use SBOM + SLSA + Sigstore to verify build artifacts
• Use Falco/Tetragon to catch runtime anomalies
• Use Vault to lifecycle secrets
• Use OPA/Kyverno to add guardrails at the deploy stage
• Use GUAC/Dependency-Track to make incident response a five-minute answer

The tools are many, the standards are in place, and what remains is execution.

References

• Tailscale: tailscale.com
• Cloudflare Zero Trust: cloudflare.com/zero-trust
• Wiz: wiz.io
• Sigstore cosign: github.com/sigstore/cosign
• SLSA framework: slsa.dev
• CycloneDX: cyclonedx.org
• SPDX: spdx.dev
• Trivy: github.com/aquasecurity/trivy
• Falco: github.com/falcosecurity/falco
• Tetragon: github.com/cilium/tetragon
• Open Policy Agent: openpolicyagent.org
• OpenSSF: openssf.org
• CISA KEV catalog: cisa.gov/known-exploited-vulnerabilities-catalog
• NIST CSRC: csrc.nist.gov
• IETF SCITT: ietf.org/doc/draft-ietf-scitt-architecture