LabHub

Blog

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

2026-05-16 · 22 min read · #cloud-security#zero-trust#sbom#slsa#cspm#cnapp#wiz#falco#sigstore#vault#tailscale#cloudflare-zero-trust#supply-chain#devsecops

한국어English日本語

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.

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.

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.

Generators have effectively consolidated into four.

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.

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.

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.

Typical question examples.

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 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.

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

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.

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.

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.

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.

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.

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.

ToolAgentMulticloudIaC integrationRuntimeCIEMPrice (SMB→Ent)
WizagentlessAWS/Azure/GCP/OCIstrongWiz Defendstrongmid-high
Orca SecurityagentlessAWS/Azure/GCPmidmidstrongmid-high
Prisma CloudbothAWS/Azure/GCP/OCI/Alibabastrongstrongstronghigh
Sysdig SecureagentAWS/Azure/GCPmidvery strong (Falco)midmid
Aqua SecurityagentAWS/Azure/GCPstrongstrongmidmid-high
Snyk CloudagentAWS/Azure/GCPstrongweakmidmid
Defender for CloudagentAzure-firstmidmidmidvalue
AWS Security Hubn/aAWS onlyweakn/an/afree + usage
GCP SCCn/aGCP onlyweakn/an/afree + Premium
Lacework FortiCNAPPagentAWS/Azure/GCPmidmidmidmid
Tenable Cloud SecurityagentlessAWS/Azure/GCPmidweakvery strongmid

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.

ToolModelFree tierIdentity integrationSelf-hostedStrength
Cloudflare Zero Trustglobal edge50 seatsOkta/Google/Azure/GitHubpartial (Tunnel)global POP, edge caching
Tailscalemesh P2P100 devicesOkta/Google/Azure/GitHubHeadscaleidentity, UX, ACL
Twingategateway2 users / 5 resourcesOkta/Google/Azure/GitHubpartialagentless, price
Zscaler ZPASASEnoneSAML/OIDCnoneenterprise PoC
NetskopeSASEnoneSAML/OIDCnoneDLP/CASB integration
Palo Alto Prisma AccessSASEnoneSAML/OIDCnoneNGFW integration
OpenZitimesh100% OSSSAML/OIDCfullself-hosted
HashiCorp BoundarybrokerOSS + EntOIDC/LDAPfulldirect Vault integration

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.

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.

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.

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.

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

References

Read the original: https://www.youngju.dev/blog/culture/2026-05-16-cloud-security-zero-trust-sbom-slsa-cspm-wiz-falco-sigstore-vault-2026-deep-dive.en

Comments

No comments yet.

Sign in to leave a comment