クラウドセキュリティ 2026 完全ガイド - Zero Trust・SBOM/SLSA・CSPM/CNAPP・Wiz・Falco・Sigstore・Vault・Tailscale・Cloudflare 徹底解説

はじめに — 2026年5月、クラウドセキュリティは「サプライチェーン+ランタイム」が中心になった

2024年3月のXZ Utilsバックドア(CVE-2024-3094)は、クラウドセキュリティの中心テーマを一夜にして変えた。「ファイアウォールを置けば大丈夫」という時代は終わり、これからはビルド時点で入り込む悪性コードと、ランタイムで起こる異常挙動こそが本当の脅威だ。2026年5月時点の市場もこの流れに沿っている。Wizは2025年中盤にGoogle買収交渉から方向転換し、自社で200億ドル超のIPOを目指す方向に切り替えた。TailscaleはアイデンティティベースのメッシュVPNでシリーズCの評価額14億ドルに到達し、SigstoreはCNCFのGraduated段階に達した。

本稿はマーケティングのマトリックスではない。「2026年プロダクションクラウドセキュリティスタックの7レイヤー」を正直に描く。Zero Trustネットワークアクセス(ZTNA)、CSPM/CNAPP、SBOM/SLSAサプライチェーン、ランタイムセキュリティ、シークレット/PAM、IaC/ポリシー・アズ・コード、そしてガバナンス/コンプライアンスまで、実際の設定例とともに比較する。

クラウドセキュリティ2026スタック — 7レイヤーに分解する

まず全体像から。2026年の標準的なクラウドセキュリティスタックは次の7レイヤーに分かれる。

1. ネットワーク / Zero Trust(ZTNA): VPN代替、アイデンティティベースのマイクロセグメンテーション
2. クラウド姿勢管理(CSPM/CNAPP): 誤設定されたクラウドリソースの検出、コンテナイメージとランタイムまで一画面で
3. サプライチェーンセキュリティ(SBOM/SLSA): ビルド成果物の出所、完全性、依存関係の可視化
4. ランタイムセキュリティ: コンテナ/ノード上の異常syscall検知
5. シークレット / PAM / IGA: パスワード、APIキー、証明書、権限のライフサイクル
6. IaC + ポリシー・アズ・コード: Terraform/K8sマニフェストの段階のガードレール
7. ガバナンス / コンプライアンス: ISMS-P、SOC 2、NIS2、GDPR、韓国個人情報保護法、日本APPI

各レイヤーを1〜2つのツールで担っていた時代は終わった。サプライチェーン事故はZTNAポリシーで止まらず、ランタイム事故はCSPMスコアでは捕まらない。統合プラットフォーム(CNAPP)の流れが加速した理由だ。以下、レイヤーごとに見ていく。

Zero Trustネットワークアクセス(ZTNA) — VPNの緩やかな終焉

Zero Trustの本質は一行に集約できる。「ネットワーク上の位置を信頼しない」だ。すべての要求はユーザーのアイデンティティ、デバイス姿勢、コンテキストに基づいて検証される。2026年5月の市場は次のように分かれている。

• Cloudflare Zero Trust(旧 Cloudflare for Teams): グローバルエッジ基盤。無料50席ティアがスタートアップの採用を加速。WARPクライアント、Access(SaaS+セルフホストアプリ)、Gateway(SWG)、Tunnel(リバースプロキシ)が一括で提供される。
• Tailscale: WireGuardベースのメッシュVPN。アイデンティティはOkta/Google/Azure AD/GitHub。コード型ACL(JSON)、タグベースのサービスルーティング。2025年のシリーズC後、SCIM、姿勢チェック、鍵ローテーションを強化。
• Zscaler: エンタープライズSASEのリーダー。ZIA(インターネットゲートウェイ)+ ZPA(アプリアクセス)+ ZDX(デジタル体験)。韓国/日本の大企業比率が高い。
• Netskope: SSE/CASB統合の強者。データ保護(DLP)、クラウドアプリ可視化が差別化点。
• Palo Alto Prisma Access: Prisma SASEパッケージの一部。Strata Cloud Managerと統合。
• Twingate: Tailscaleとしばしば比較される。エージェントレスのサイドカー、NLBなしのプライベートルーティング。
• OpenZiti: 100%オープンソースのZTNAファブリック。セルフホスト陣営。
• Boundary(HashiCorp): Vaultと直結するPAM寄りのZTNA。SSH/DB/RDPセッションブローカリングが得意。

選定基準はシンプルだ。グローバルエッジ vs セルフホスト vs メッシュアイデンティティの3軸。Cloudflareがグローバルエッジの標準、Tailscaleがメッシュアイデンティティの標準、OpenZiti/Boundaryがセルフホスト陣営の代表となる。

Tailscale ACL — コード型ネットワークポリシーの標準例

Tailscale ACLはJSONファイル1つでデバイス、ユーザー、タグ、ポート単位のアクセスを制御する。実際のACL例。

{
  "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"] }
  ]
}

このACLの価値はPRレビュー可能なネットワークポリシーである点だ。Gitにプッシュし、Slack上でレビューし、マージで反映。従来のファイアウォールルールにおける「Excelシートベースの変更管理」はもう答えにならない。

CSPMからCNAPPへ — Wiz、Orca、Prisma Cloudの統合戦争

CSPM(Cloud Security Posture Management)は元々「誤設定されたS3バケットを見つける」が主だった。2026年にはその役割が**CNAPP(Cloud-Native Application Protection Platform)**に移った。一つのプラットフォームでIaCスキャン→ビルド→レジストリ→ランタイム→データまでを一気通貫で見るという流れだ。

• Wiz: 2020年創業、2025年時点で評価額200億ドル超。エージェントレススキャンが差別化点。Wiz Code(IaC)、Wiz Cloud(姿勢)、Wiz Defend(ランタイム)でラインを分割。
• Orca Security: SideScanning特許。クラウドAPIだけでスナップショット解析。
• Lacework: Polygraphベースの挙動分析。Fortinet買収後はSASEパッケージへ。
• Prisma Cloud(Palo Alto): 旧RedLock、PureSec、Twistlock、Bridgecrewの統合。規模では最大。
• Sysdig Secure: Falcoの本家。ランタイム+CSPMの組み合わせ。コンテナ陣営に強い。
• Aqua Security: コンテナ/Kubernetesセキュリティのパイオニア。Trivyの本家。
• Snyk Cloud: 開発者ファースト。Snyk Code/Open Source/Container/IaCと統合。
• Tenable Cloud Security: 旧Ermetic買収。CIEM(権限分析)に強み。
• Microsoft Defender for Cloud: Azureネイティブ+マルチクラウド拡張。
• AWS Security Hub: GuardDuty、Inspector、Macieと統合パネル。マルチクラウドは弱い。
• GCP Security Command Center: 無料のSCC Standardと有料Premium。
• Lookout / Datadog Cloud Security: 新規参入。モバイル/可観測性に強み。

選定基準はエージェントレス vs エージェントベース、マルチクラウドの深さ、IaC統合。Wizがエージェントレスの標準、Sysdig/Aquaがエージェントベースのランタイム陣営の強者、Snykが開発者フレンドリーの代表だ。

SBOMの時代 — CycloneDXとSPDX、そして米国大統領令14028

SBOM(Software Bill of Materials)は2021年の米国大統領令14028以後、すべての連邦調達ソフトウェアの必須成果物となった。2024年にNIST SP 800-218(SSDF)が2.0に改訂されSBOM要件がより具体化され、2025年にはEU NIS2と韓国のISMS-P認証の付属ガイドもSBOM義務化の流れに合流した。日本のMETIも2024年8月に「OSS活用時のSBOM作成ガイド」v2.0を公開した。

事実上の標準は2つ。

• CycloneDX: OWASP傘下。セキュリティ陣営が主導。VEX(Vulnerability Exploitability eXchange)統合、SaaSBOM、AI/MLモデルBOMサポートが差別化点。
• SPDX 3.0: Linux Foundation傘下。ライセンス陣営が主導。SPDX 3.0(ISO/IEC 5962:2021)でセキュリティプロファイルが追加され、2つの標準の差が縮まった。

生成ツールも事実上4つに収束する。

• Syft(Anchore): イメージ/ディレクトリからSBOMを抽出。CycloneDX/SPDXの双方を出力。
• Trivy(Aqua): スキャンとSBOMを一括。CycloneDX/SPDX/Trivy独自フォーマット。
• cdxgen(CycloneDX公式): 多言語対応。SaaSBOM、Operations BOMまで。
• GitHub dependency-graphエクスポート: GitHub Advanced SecurityがSBOMを自動出力。

CycloneDX JSON SBOMの最小形は次のとおり。

{
  "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"
    }
  ]
}

SBOMの価値は単純だ。新しいCVEが出たとき、影響範囲を5分以内に答えられるか。Log4Shell、XZ Utils、そして2025年のnpmタイポスクワッティング騒動で、SBOMを持つ組織と持たない組織の差は時間単位ではなく日単位で表れた。

SLSAフレームワークとin-toto — ビルド由来証明の標準

SLSA(Supply-chain Levels for Software Artifacts)はOpenSSFが主導するビルド完全性フレームワークだ。2026年現在、v1.0が安定段階、v1.1がRC。中核は4段階のレベル。

• SLSA L1: ビルドプロセスを文書化
• SLSA L2: ホスト型ビルド + 署名済みprovenance
• SLSA L3: ビルド隔離(改竄不能なprovenance)
• SLSA L4: hermetic, reproducibleなビルド

最も一般的なprovenanceフォーマットはin-toto attestationだ。predicate typeごとにSLSA provenance、SBOM、Vuln、SCAIなどを標準化する。2025年にIETF SCITT(Supply Chain Integrity, Transparency, and Trust)WGがSBOM/attestation透明性サービスのRFC草案を公開し、2026年第1四半期にWG Last Callに入った。

標準的なin-toto provenanceの例。

{
  "_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 — 署名、透明性ログ、キーレスの標準

Sigstoreは2021年にLinux Foundation傘下でスタートし、2024年にCNCFのGraduated段階に達したサプライチェーン署名プロジェクトだ。3つのコンポーネントから構成される。

• cosign: コンテナイメージ/SBOM/blob署名のCLI
• Fulcio: キーレス(keyless)OIDCベースの短期証明書発行CA
• Rekor: 追記専用の透明性ログ(transparency log)

中核はキーレス署名だ。開発者は秘密鍵を保存する必要がなく、OIDC IDトークン(GitHub Actions、Google、Microsoft)でFulcioに署名要求を送り、Fulcioが短期X.509証明書を発行する。署名はRekorに記録され、Rekorはマークルツリーで改竄を防ぐ。

cosignの典型的なフロー。

# 1) キーレス署名 (GitHub Actions OIDC)
cosign sign \
  --identity-token "$ACTIONS_ID_TOKEN" \
  ghcr.io/acme/checkout-api@sha256:abc123def456

# 2) SBOMをattestationとして添付
cosign attest \
  --predicate sbom.cdx.json \
  --type cyclonedx \
  ghcr.io/acme/checkout-api@sha256:abc123def456

# 3) 検証 (デプロイ時)
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

2024年のXZ Utilsバックドア以後、GitHub Actions、GitLab CI、npm、PyPIが急速にSigstore統合を進めている。npmは2023年からnpm publish --provenanceでSigstore provenanceを発行しており、2026年第1四半期時点でトップ1000パッケージのうち60%以上がprovenanceを持つ。

GUAC — SBOMのグラフデータベース

SBOMとattestationを集めたら、次の問いは「どう検索するか」だ。1万のマイクロサービスに散らばるSBOMをgrepするのは答えにならない。GUAC(Graph for Understanding Artifact Composition)が2023年に登場した理由だ。

• 入力: SBOM(CycloneDX/SPDX)、in-toto attestation、SLSA provenance、Sigstore Rekorログ
• 保存: Neo4jのようなグラフDB(またはArangoDB、PostgreSQL)
• 出力: GraphQL API + CLI

典型的な質問例。

• 「Log4j 2.17.1以下を使うコンテナイメージをすべて見つけて」
• 「Sigstore署名のないプロダクションデプロイをすべて見つけて」
• 「このnpmパッケージの直接・間接依存のうち平均評価が1点以下のパッケージを見つけて」

GUACは2026年5月にv1.0 GAを控えており、Kusariが商用マネージドサービスを提供している。Dependency-Track(OWASP)がSBOMインデックス陣営のもう一つの主要選択肢だ。

Trivyイメージスキャン — 最も使われるOSSスキャナ

TrivyはAqua Securityが作ったOSSスキャナで、コンテナイメージ、ファイルシステム、Gitリポジトリ、K8sマニフェスト、Terraformなどを1ツールで見る。2026年5月時点でGitHubスター23k、Kubernetes陣営の事実上の標準だ。

# イメージスキャン (CVE + ライセンス + シークレット + 誤設定)
trivy image \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  --format sarif \
  --output trivy.sarif \
  ghcr.io/acme/checkout-api:v1.42.0

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

# Terraformポリシー検査
trivy config ./infra/terraform

# Kubernetesクラスタ姿勢
trivy k8s --report summary cluster

代替陣営も堅実だ。**Grype(Anchore)**はSyftと組み合わせてSBOMファーストワークフローの標準、Snyk Containerは開発者UX優先、Anchore Enterpriseはポリシーエンジンの強者。**OSV-Scanner(Google)**はOSV.devデータセットベースで正確なマッチングが強み。

ランタイムセキュリティ — Falco vs Tetragon、eBPFの時代

ランタイムセキュリティは「すでにデプロイされたコンテナ内で起こる異常挙動」を見る。2026年5月時点で2つの陣営に分かれる。

• Falco(CNCF Graduated): Sysdigが作り、2024年1月にCNCF Graduated。libbpfベースのeBPFドライバ。ルールベース検知。
• Tetragon(Isovalent/Cisco): Ciliumの本家。eBPF+LSMフック。ポリシー強制(enforcement)まで。
• KubeArmor: AccuKnox主導。LSM(AppArmor、BPF-LSM)ベース。
• Calico Enterprise / Calico Cloud(Tigera): ネットワークポリシー+ランタイムの結合。
• Datadog Cloud Security: SaaSファーストのランタイムセキュリティ。Datadog可観測性と統合。

FalcoルールはYAMLで書く。「コンテナ内でシェルが起動した」を捉えるルール例。

- 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は類似のポリシーをポリシー・アズ・コード(K8s CRD)で書き、さらにLSMフックで遮断まで行う。Falcoが検知陣営の標準、Tetragonが検知+遮断陣営の新星だ。

シークレット管理 — Vault、Doppler、Infisical

シークレットはセキュリティで最もよくある事故ポイントだ。2024年のGitGuardian "State of Secrets Sprawl"レポートによれば、GitHub公開リポジトリで露出したシークレットは1290万件、2025年には1740万件に増加した。ツールの選択肢は次のとおり。

• HashiCorp Vault: 事実上の標準。2024年のIBM買収後のライセンス変更(BSL)で議論を呼んだが、市場シェアは依然1位。動的シークレット(DB認証情報の自動発行)、Transit(EaaS)、PKI、KVが中核のシークレットエンジン。
• OpenBao: Vault BSL移行に対応するLinux Foundation OSSフォーク。2025年v2.0 GA。
• AWS Secrets Manager / SSM Parameter Store / GCP Secret Manager / Azure Key Vault: クラウドネイティブ陣営。単一クラウドなら十分。
• Doppler: 開発者UX優先。.envファイル同期から始まった。
• Infisical: OSS+SaaS。DopplerのOSS代替。
• AKEYLESS: KMS-as-a-Serviceのポジショニング。分散フラグメントベースの鍵管理(DFC)。
• CyberArk Conjur: エンタープライズPAMの本家。K8s/CI寄りのOSSライン。

PAM(Privileged Access Management) / IGA(Identity Governance & Administration)は別市場だ。

• CyberArk: PAM 1位。EPM(Endpoint Privilege Manager)パッケージ。
• BeyondTrust: PAM 2位。Password Safe、Privileged Remote Access。
• Delinea(Thycotic+Centrifyの合併): PAM 3位。
• SailPoint / Saviynt / Okta: IGA + アイデンティティ。

Vault動的シークレット — 静的シークレットの終わり

Vaultの核となる価値は「シークレットを事前に作っておかず、必要時に発行する」だ。PostgreSQLのユーザー/パスワードを要求ごとに新規発行し、TTL終了時に自動失効させる。

# vaultサーバ設定 (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) DBシークレットエンジン有効化
vault secrets enable database

# 2) PostgreSQL接続登録
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) ロール定義 (TTL 1時間)
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) ユーザー発行
vault read database/creds/readonly

発行されたユーザーはTTL終了とともに自動で失効する。シークレットがGit、wiki、Slackに漏れても1時間後には無効になる。これがZero Trustシークレットモデルの本質だ。

IaCスキャン — Checkov、tfsec、KICS、Terrascan

Terraform/CloudFormation/K8sマニフェストはビルド成果物だが、同時に「コード」でもある。コードはスキャンできる。

• Checkov(Bridgecrew→Palo Alto): 最も広く使われるOSS。Terraform、CloudFormation、K8s、ARM、Bicep、Helm、Dockerfile、Kustomizeまで。
• tfsec(Aqua): Trivyに統合されたが、単独CLIも継続。
• KICS(Checkmarx): 200以上のスキャンルール。マルチIaC。
• Terrascan(Tenable): OPA Regoベースのポリシーエンジン。
• Snyk IaC: 開発者フレンドリー。Snykパッケージの一部。

Checkovの実行は一行で済む。

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

代表的な誤設定パターン3つ。

• S3バケットのpublic-read ACL(CKV_AWS_20)
• RDSストレージ暗号化未使用(CKV_AWS_17)
• セキュリティグループの0.0.0.0/0 22番ポート開放(CKV_AWS_24)

この3つは、ほぼすべての事故報告書の1、2、3番目だ。

ポリシー・アズ・コード — OPA Gatekeeper、Kyverno、Conftest、Cedar

K8sクラスタに入るすべてのリソースをadmission webhookの段階で検証するのがポリシー・アズ・コードの流れだ。

• OPA(Open Policy Agent) + Gatekeeper: CNCF Graduated。Rego DSL。
• Kyverno: YAMLベース。OPAより学習曲線が緩い。
• Conftest: OPA RegoをCI/CDで実行するCLI。
• Cedar(AWS): AWS Verified Permissions / Cedarポリシー言語。2023年にOSS化。

OPA Regoで「すべてのデプロイはリソース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])
        }

Kyvernoの同じポリシーは短い。YAML 1ファイルで済む。「OPAは表現力、Kyvernoは可読性」という定説は2026年も有効だ。

シークレットスキャニング — gitleaks、truffleHog、GitGuardian

コード/コミット/イメージに露出したシークレットを見つけるレイヤー。

• gitleaks: OSS 1位。pre-commitフック+CIフレンドリー。
• truffleHog: SourceAgent陣営のOSS。検証済み(verified)シークレットの分類が差別化点。
• GitGuardian: SaaS 1位。1000以上のシークレット種別を検出、自動遮断(Honeytoken)。
• Spectral(Checkpoint買収): IaC+シークレット+SBOMを統合するSaaS。

運用フローはpre-commit+CI+定期スキャン(週次full-history)の三重だ。

SAST/DASTとSCA — GitHub Advanced Security、Snyk、FOSSA、Mend

コード自体を見るSAST(Static)、実行中のアプリを見るDAST(Dynamic)、オープンソース依存を見るSCA(Software Composition Analysis)は別市場だ。

• GitHub Advanced Security: CodeQL(SAST)+ Dependabot(SCA)+ Secret Scanning。GitHubユーザーには最も自然な選択。
• GitLab Dependency Scanning: GitLab Ultimateパッケージ。
• Snyk: 開発者ファースト。Snyk Code(SAST)+ Open Source(SCA)+ Container + IaC。
• FOSSA: ライセンスコンプライアンスに強い。M&Aデューデリでよく出てくる。
• Mend(旧WhiteSource): SCA市場の初期リーダー。エンタープライズライセンス分析。
• Sonatype Lifecycle / Nexus IQ: Maven Centralの本家。エンタープライズSCA。
• Veracode / Checkmarx: エンタープライズSAST陣営。

2026年の流れは単純だ。GitHubに自然に統合されるツールを使うか、Snykのようなマルチ-VCSツールを使うか、どちらかだ。

CSPM/CNAPPツールマトリックス — 2026年5月時点

選定の実用基準を表で整理する。

選定は既存のEDR/SIEMとの統合、マルチクラウドの深さ、価格、エージェントレスへの選好で絞り込む。

ZTNAツール比較 — グローバルエッジ vs メッシュ vs セルフホスト

ZTNAも同じ要領で整理する。

Cloudflare Zero Trust + Tailscaleの組み合わせは2026年のSMBの標準解だ。Cloudflareが外部→内部のSaaS/アプリアクセス、Tailscaleが内部→内部のデバイス/サービスメッシュ。

韓国 / 日本 / EUコンプライアンス — 2026年の変化

法規制側も急速に動いている。

• 韓国ISMS-P: 2024年12月の改定で、SBOM管理項目が付属として明記された。2025年7月施行。サプライチェーンセキュリティ統制(2.10.1)が新設された。
• 韓国個人情報保護法: 2023年9月の改定施行以後、仮名情報、ポータビリティ権、自動化された意思決定への拒否権が追加された。2026年はEU GDPR十分性認定が韓国に適用中。
• 日本APPI: 2024年4月改定法施行。仮名/匿名加工情報、外国事業者の報告義務強化。2026年4月の追加改正でデータブローカー登録制が導入された。
• 日本METI SBOMガイドライン: 2024年8月v2.0、2026年2月v3.0。製造業/IoT優先。
• EU NIS2: 2024年10月にEU加盟国で施行。18産業の「必須/重要」事業者にICTサプライチェーンセキュリティ義務を課す。SBOM、事故通報24時間、パッチSLAが中核。
• EU CRA(Cyber Resilience Act): 2024年12月発効、2027年12月本格適用。デジタル要素を持つすべての製品にSBOM義務化。
• 米国大統領令14028: 2021年から連邦調達でSBOM要求。2025年NIST SP 800-218 SSDF 2.0。
• PCI DSS 4.0: 2025年3月にv4.0.1へマイナー更新。SBOM、認証強化、ペイメントページのスクリプト管理(6.4.3)が中核。

耐量子暗号(PQC) — 2026年のスタートライン

2024年8月にNISTがML-KEM(鍵交換)、ML-DSA(署名)、SLH-DSA(ハッシュベース署名)の3アルゴリズムを標準として確定した。2026年5月時点の状況。

• Cloudflare: 2024年からML-KEM-768とX25519-MLKEM768ハイブリッドKEXをTLS 1.3ハンドシェイクにデフォルト適用。2026年第1四半期時点でトラフィックの35%がPQCハイブリッド。
• Google: Chrome 124(2024年4月)からX25519MLKEM768がデフォルト有効。
• AWS KMS: 2024年9月からML-DSA署名をサポート。
• OpenSSH: 9.0からsntrup761x25519ハイブリッド。9.9(2024年9月)でML-KEMを追加。

CRAのSBOM義務化とPQC移行は2026〜2028年の間に並行して進む。SBOMに「このライブラリがどの暗号プリミティブを使うか」を記録するCBOM(Cryptographic Bill of Materials)がCycloneDX 1.6に追加された理由だ。

2025年npmタイポスクワッティング騒動とサプライチェーン脅威マップ

2025年の1年間にnpm陣営で発生した主要サプライチェーン事故。

• 2025年1月: eslint-config-prettierの変種7種のタイポスクワッティング、累計ダウンロード230万件。
• 2025年4月: lottie-playerの汚染(compromise)事故。正規パッケージへのパスワード窃取ペイロード注入。CDNキャッシュ無効化に36時間。
• 2025年6月: PyPIでcolorama/requestsの64種のタイポスクワッティング変種を一斉摘発。
• 2025年9月: Solana SDKを模倣したnpmパッケージからウォレット鍵が窃取される。被害総額80万ドル。
• 2025年11月: GitHub Actionsワークフローのpull_request_target誤用によるシークレット漏洩事故24件。

対応の標準は単純だ。lockfile + 完全性ハッシュ + Sigstore検証 + 変更隔離ビルド。加えてnpmは2026年1月から--require-provenanceフラグをデフォルト有効化する方向を発表した。

標準ビルドパイプライン — 2026年の「安全なビルド」の絵

最後にすべてをまとめた標準パイプラインを整理する。

1. PR段階: gitleaks、Snyk Code/CodeQL、Checkov、dependency review action
2. ビルド段階: hermeticコンテナビルド、SLSA L3ビルダー(GitHub-hosted runner + reusable workflow)
3. 成果物段階: cosignキーレス署名、SBOM添付(CycloneDX)、SLSA provenance attestation
4. レジストリ: GHCR/ECRのimmutable tag、Sigstore署名ポリシー
5. デプロイ段階: K8s admission webhook(OPA/Kyverno)が署名+provenanceなしで拒否
6. ランタイム段階: Falco/Tetragonルール、CSPM(Wiz/Sysdig)が姿勢+driftを監視
7. 事故対応: SBOMインデックス(GUAC/Dependency-Track)で影響範囲を5分以内に回答

この7段階をすべて備える組織は2026年5月時点でグローバルトップ1%程度だ。ただし1〜3段階はOSSだけで可能で、4〜6段階はクラウドネイティブ+CNAPP1つでまかなえる。

おわりに — 2026年クラウドセキュリティの一行まとめ

2026年のクラウドセキュリティのエッセンスは一行に凝縮される。「ファイアウォールの内側で起こることのほうが怖い」。XZ Utilsバックドアはビルド時点で入り込み、2025年のnpmタイポスクワッティングは依存ツリーの奥深くで起きた。そしてSBOMを持たない組織は誰一人として影響範囲を即答できなかった。

答えはシンプルだ。

• Zero Trustでネットワーク信頼を消し
• CNAPPでクラウド姿勢を一画面に集め
• SBOM + SLSA + Sigstoreでビルド成果物を検証し
• Falco/Tetragonでランタイムの異常を捕まえ
• Vaultでシークレットをライフサイクル管理し
• OPA/Kyvernoでデプロイ段階のガードレールを設け
• GUAC/Dependency-Trackで事故時の5分回答を作る

ツールは揃い、標準も整い、残るは実行だけだ。

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