コンテナ&サプライチェーンセキュリティ 2026 ディープダイブ — Trivy / Grype / Snyk / Sysdig / Tetragon / Falco / Cosign / Sigstore 総まとめ

「サプライチェーンセキュリティはもはや『チェックボックス・コンプライアンス』ではない。xzは、最も信頼されているOSSメンテナーですら2年がかりのソーシャルエンジニアリングの標的になり得ることを我々に教えた。」 — Filippo Valsorda、Goセキュリティリード、GopherCon 2025基調講演

2024年3月29日、Andres FreundはPostgreSQLのビルド遅延をデバッグしている最中に、xz-utils 5.6.0/5.6.1に仕掛けられたバックドア(CVE-2024-3094)を発見した。ほぼすべてのLinuxディストリビューションに混入する寸前だったこの事件は、コンテナベースイメージ全体のSBOMトレーサビリティ、署名、来歴(provenance)要件のハードルを一気に押し上げた。1年後の2025年12月にはEUの**Cyber Resilience Act (CRA)**が施行され、EU域内で販売されるすべてのデジタル製品にSBOM提出と脆弱性開示が義務付けられた。米国もEO 14028とNIST SSDF(SP 800-218)で同じ道を進んでいる。

2026年5月時点で「コンテナセキュリティ」はもはや単一のツールカテゴリではない。**イメージスキャン(ビルド時)/レジストリポリシー(プッシュ時)/アドミッション制御(デプロイ時)/ランタイムセキュリティ(実行時)/署名&来歴(全段階)**という5層の防御線が必要だ。本稿では、Trivy、Grype、Snyk、Sysdig、Anchore、Twistlock、Tetragon、Falco、Cosign/Sigstore、Notary v2、in-toto、SLSA、CycloneDX、SPDX、distroless、gVisor、Kata Containers、OPA Gatekeeper、Kyvernoを一箇所にまとめる。

1. 2026年コンテナセキュリティ地図 — 5層の防御線

まずはカテゴリを明確にしておく。

xz事件の教訓は一行に集約される — この5層のうち単一に依存してはいけない。ビルド時CVEスキャンは未公開バックドアを捕まえられず、署名検証はメンテナー自身が署名した悪意あるコードを通過させ、ランタイムセキュリティは「正常syscallを装った」バックドアを取り逃がす。多層防御こそが答えだ。

2. イメージスキャナー比較 — Trivy / Grype / Snyk / Anchore / Docker Scout

Trivy (Aqua Security、Apache 2.0)は2026年5月時点で事実上の標準だ。GitHub Star 22k超、Kubernetes Security SIGの推奨ツール、EKS/GKE/AKSセキュリティガイドに明記。強みはシングルバイナリ+8カテゴリ統合スキャン — OSパッケージCVE、言語依存性、シークレット、設定不備、ライセンス、Kubernetesマニフェスト、Terraform、Helmチャートを一本で処理する。

Grype (Anchore、Apache 2.0)はTrivyと真っ向勝負する。姉妹ツールSyft(SBOMジェネレータ)と組み合わせると強力。Anchore EngineのOSS後継であり、NVD + GitHub Advisory + 独自キュレーションDBを使う。

Snyk Container(商用)は開発者ワークフロー統合に強い。PRへの自動コメント、JIRA連携、自動fix提案、ベースイメージ自動推薦(CVE少ない版へ)。難点はライセンス費用 — 100コンテナを超えると通常は年間数千万円規模。

Sysdig Secure(商用)はFalco発祥企業のフルスタックプラットフォーム。イメージスキャン+ランタイム+コンプライアンス+IaC統合。AWS Marketplace 1ティアISVでFortune 500で人気。

Anchore Enterprise(商用)は政府・金融市場に強い。SBOM中心アーキテクチャ、FedRAMP / DISA STIG認証保有、米国防総省Iron Bankコンテナレジストリのゲートキーパー。

Docker ScoutはDocker HubとDocker Desktopに統合された無料(一部)ツール。軽量な入口だがエンタープライズ機能は限定的。

3. Trivy実践 — 一発でイメージからSBOMまで

最も典型的なシナリオを見てみる。nginx公式イメージをスキャンしてCVEを洗い出し、SBOMを生成し、CIで閾値を超えたら失敗させる流れ。

# 1) イメージCVEスキャン(CRITICAL/HIGHのみ、修正可能なものだけ)
trivy image \
  --severity CRITICAL,HIGH \
  --ignore-unfixed \
  --format table \
  nginx:1.27-alpine

# 2) SBOM生成(CycloneDX 1.5形式)
trivy image \
  --format cyclonedx \
  --output nginx-sbom.cdx.json \
  nginx:1.27-alpine

# 3) SBOMから再スキャン(イメージ再pull不要)
trivy sbom nginx-sbom.cdx.json

# 4) CIゲート — CRITICAL 1件でもexit 1
trivy image \
  --severity CRITICAL \
  --exit-code 1 \
  --ignore-unfixed \
  myapp:${GIT_SHA}

# 5) シークレットスキャン(.git, .env, AWSキーなど)
trivy fs --scanners secret,misconfig ./

# 6) Kubernetesマニフェストスキャン
trivy config --severity HIGH,CRITICAL ./k8s/

肝は--ignore-unfixedオプション。CVEがあってもパッチがなければ手の打ちようがないので、修正可能なものだけをゲートにかけるのが運用上理に適う。ただし6ヶ月以上未修正のCVEは別途追跡する必要がある。

4. CVEマッチングDB — NVD / OSV / GitHub Advisoryの違い

スキャナーが「脆弱性あり」と言うとき、どのDBを参照しているかが精度を左右する。2026年現在、主要DBは3つ。

NVD (National Vulnerability Database)はNIST運営、CVEの本家。問題はバックログ。2024-2025年はNISTの人員不足でenrichment(CPEマッチング、CVSSスコア付与)が6ヶ月以上遅延し、新規CVE情報の空白が大きかった。

**OSV (Open Source Vulnerabilities)**はGoogleが2021年に開始。パッケージ-CVEマッピングが正確(NPM、PyPI、Go、Rustなどパッケージマネージャーネイティブ)。API無料、JSONスキーマも明快。TrivyとGrypeはどちらもOSVを補助ソースとして利用する。

GitHub Advisory DatabaseはGitHub Security Lab + Dependabotがキュレーション。NPM/PyPI/RubyGems領域ではNVDより早く情報が上がる。

運用Tips — Trivyは3つすべてを組み合わせて参照する。trivy image --vuln-type os,library --db-repository ghcr.io/aquasecurity/trivy-dbでDBミラーを社内に置けばエアギャップ環境でも動く。

5. SBOM標準 — CycloneDX対SPDX

SBOM義務化時代の二大標準。

CycloneDX (OWASP)はセキュリティ中心。VEX(Vulnerability Exploitability eXchange)を同一ドキュメントにインラインできる。JSON/XML/protobuf すべて対応。CISA 2024ガイドラインで推奨。米国医療機器FDA、EU CRAともCycloneDXを第一選択と見ている。

SPDX(Linux Foundation)はライセンスコンプライアンス中心から出発。ISO/IEC 5962:2021として国際標準化。ライセンスメタデータがより豊富で、Kubernetes / CNCFプロジェクトはSPDXを採用。

両形式は変換可能 — cyclonedx-cli convert --input-format spdxjson --output-format jsonまたはその逆。Syftは両形式とも出力できる。

# SyftでSBOM生成
syft nginx:1.27 -o cyclonedx-json=nginx.cdx.json
syft nginx:1.27 -o spdx-json=nginx.spdx.json

# ディレクトリSBOM
syft dir:./myapp -o cyclonedx-json

# 同じSBOMをGrypeでスキャン
grype sbom:nginx.cdx.json --fail-on high

6. SLSA — ビルド来歴保証の4段階

**SLSA (Supply-chain Levels for Software Artifacts)**はGoogle発、OpenSSFが管理するビルド完全性フレームワーク。核となる問いは「ビルドされたアーティファクトは本当にそのソースから、そのビルドシステムで作られたか」の証明。2026年にはSLSA v1.0が広く採用された。

GitHub Actionsは2023年にSLSA L3ビルダーを公開(slsa-framework/slsa-github-generator)。Google Cloud Build、AWS CodeBuildもL3対応。SLSA Provenanceはin-toto attestationフォーマットで生成される。

xzバックドアはSLSAで防げただろうか? 部分的にのみそうだ。xzのビルドシステム自体は侵害されていなかったため、SLSA L3 attestationは発行されたであろう。ただし**2人レビュー(L4)**であれば、単独メンテナーJia Tanの単独マージはできなかった。SLSA L4はまだほぼすべてのOSSで未達成のままだ。

7. Cosign / Sigstore — キーレス署名の革命

Cosign(Sigstoreプロジェクト)は2022年にOCIイメージ署名のゲームを変えた。従来型PKIは鍵管理が悲惨に難しい — 鍵紛失、鍵盗難、鍵ローテーション。Cosignのキーレス署名はOIDC IDトークンで短期(10分)証明書を発行して署名する。

3つの構成要素:

• Fulcio: 短期X.509証明書を発行するCA。OIDC IDトークン(GitHub OIDC、Google、Oktaなど)を検証し証明書を発行
• Rekor: 追記専用の透明性ログ(Tile-Based Merkle Tree)。すべての署名が公開記録され、事後改ざん不可
• Cosign CLI: クライアントツール

# 1) キーレス署名(GitHub Actions OIDC使用)
COSIGN_EXPERIMENTAL=1 cosign sign \
  ghcr.io/myorg/myapp@sha256:abc...

# 2) 検証 — 誰が署名したか(certificate identity)、どこで(issuer)
cosign verify \
  --certificate-identity-regexp="^https://github.com/myorg/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc...

# 3) attestation署名(SLSA provenanceなど)
cosign attest \
  --predicate provenance.json \
  --type slsaprovenance \
  ghcr.io/myorg/myapp@sha256:abc...

# 4) SBOMをOCIアーティファクトとして一緒にプッシュ
cosign attach sbom \
  --sbom nginx-sbom.cdx.json \
  ghcr.io/myorg/myapp@sha256:abc...

2026年時点でSigstore Rekor publicログには1億5千万件以上のエントリが蓄積。Kubernetes、CNCFプロジェクトの多数、そしてPyPI/RubyGemsもSigstore署名を段階的に導入中。

8. Notary v2対Cosign — 二大潮流の違い

Notary v2はDockerが開始したイメージ署名標準の後継。2024年1.0リリース。CNCF Incubating。OCI 1.1 Artifact仕様の上に直接構築されており、OCI互換レジストリならどこでも動作する。

CosignとNotary v2の比較:

実際にはKubernetes / CNCFエコシステムはCosign、エンタープライズ/金融PKIベースはNotary v2という分岐が固まりつつある。1組織での同時運用も可能 — Cosignでdev、Notary v2でprodリリース。

9. in-toto Attestation — provenanceの標準フォーマット

in-totoはCMU発のサプライチェーン完全性フレームワーク(2016)。要点は「各ビルドステップのメタデータを署名付きattestationとして残しチェーンを検証する」。2026年にはSLSA Provenance、SBOM attestation、VEXがすべてin-toto envelopeとして標準化された。

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/myorg/myapp",
    "digest": { "sha256": "abc123..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/heads/main",
          "repository": "https://github.com/myorg/myapp",
          "path": ".github/workflows/release.yml"
        }
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner" },
      "metadata": {
        "invocationId": "https://github.com/myorg/myapp/actions/runs/123"
      }
    }
  }
}

このstatementにDSSE(Dead Simple Signing Envelope)で署名すればattestation完成。Cosignのcosign attestが自動で作ってくれる。

10. Distrolessイメージ — 攻撃表面をゼロに近づける

distrolessはGoogleが始めたベースイメージ哲学。「本番イメージにシェルもパッケージマネージャーもlibc以外の基本ユーティリティも入れるな」。コンテナエスケープ後に攻撃者が使えるツールを丸ごと取り除く。

# マルチステージビルド — ビルドステージは道具フルセット、ランタイムはdistroless
FROM golang:1.23 AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/app ./cmd/server

# distroless static(nonrootユーザー内蔵)
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /out/app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]

distrolessバリアント — static(Goのような静的バイナリ向け)、base(glibc + 証明書)、cc(C/C++ libstdc++)、java21-debian12、python3-debian12、nodejs20-debian12。

代替案: Wolfi(Chainguard)はdistrolessにパッケージマネージャー(apk)を加えた「セキュリティ・ファーストOS」。CVE 0イメージの約束、24時間以内パッチ。Chainguard Imagesは商用だが人気急増中。

2026年のトレンドはchiseled containers — Microsoftが.NET 8から導入。Ubuntuベースから必要なファイルだけ抽出して100MBを30MBに圧縮。

11. gVisor / Kata Containers — サンドボックスランタイム

デフォルトのOCIランタイム(runc、containerd)はLinuxカーネルをホストと共有する。カーネル脆弱性がすなわちコンテナエスケープだ。サンドボックスランタイムはその間に隔離層を追加する。

gVisor(Google、Apache 2.0)はGoで書かれたユーザースペースカーネル。コンテナのsyscallを横取りし自前実装カーネルが処理。高速起動、ミッドティア隔離。GKE Sandbox、App Engineスタンダード環境で使用。

Kata Containers(OpenStack Foundation)は軽量VM。コンテナごとにKVMマイクロVMを起動。起動0.5秒級、隔離はVM級。Intel Clear Containers + Hyper.shの後継。Azure Confidential Containers、Alibaba Cloud Sandboxed Containerで使用。

# Kubernetes RuntimeClass — Pod単位でサンドボックスを選ぶ
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: untrusted-workload
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: ghcr.io/myorg/user-code:latest

12. Falco — eBPFベースのランタイム脅威検知

Falco(2024年CNCF Graduated)はコンテナランタイムセキュリティの事実上の標準。Sysdigが開発しCNCFに寄贈。核心はsyscallレベルのルールエンジン — /etc/shadowの読み取り、nsenter実行、コンテナ内でのパッケージマネージャー実行などの不審な振る舞いを即座にアラートする。

2026年Falcoはmodern eBPFプローブ(libbpfベース)をデフォルトに。カーネル5.8+が必要。旧来のカーネルモジュール / kprobeはdeprecated。

Falcoルール例:

- rule: Shell Spawned in Container
  desc: A shell was spawned in a container — likely interactive intrusion
  condition: >
    spawned_process and container
    and shell_procs
    and proc.tty != 0
    and not user_known_shell_spawn_activities
  output: >
    Shell spawned in container (user=%user.name container_id=%container.id
    container_name=%container.name shell=%proc.name parent=%proc.pname
    cmdline=%proc.cmdline image=%container.image.repository)
  priority: WARNING
  tags: [container, shell, mitre_execution]

- rule: Write Below Etc
  desc: Write to /etc directory — possible persistence attempt
  condition: >
    write_etc and not proc.name in (allowed_etc_writers)
  output: >
    File below /etc opened for writing (user=%user.name
    command=%proc.cmdline file=%fd.name container=%container.id)
  priority: ERROR
  tags: [filesystem, mitre_persistence]

Falcoはsyscall発生時点で評価するためほぼリアルタイム(microsecond単位)。出力はstdout、syslog、gRPC、HTTP(SOC統合)、Slack/PagerDutyすべて可能。

13. Tetragon — eBPFベース次世代ランタイムセキュリティ

Tetragon(Isovalent / Cilium ファミリ、Apache 2.0)はFalcoに対する強力な対抗馬。2023年に発足し2025年v1.3で安定化。差異は2点。

第一にeBPFのフル活用。Falcoはsyscallフック中心、TetragonはsyscallにLSMフック、kprobe、uprobeまで活用する。第二にリアルタイム遮断(prevention)。Falcoは検知後アラートが基本だが、TetragonはeBPF内で直接sigkill、syscall返り値の改変など強制遮断ができる。

# TracingPolicy CRD — Tetragonのルール
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-cryptominer
spec:
  kprobes:
  - call: "fd_install"
    syscall: false
    args:
    - index: 0
      type: int
    - index: 1
      type: "file"
    selectors:
    - matchArgs:
      - index: 1
        operator: "Postfix"
        values:
        - "xmrig"
        - "minerd"
      matchActions:
      - action: Sigkill

このポリシーはxmrigまたはminerdバイナリが開かれた瞬間にSIGKILLを飛ばす。Falcoでは検知して外部システムがkillする必要があるが、Tetragonはカーネル内で完結 — 遅延ゼロ。

14. OPA Gatekeeper対Kyverno — アドミッションコントローラ二大潮流

Kubernetesアドミッション段階 — Podがetcdに保存される前の最終ゲート — のポリシー強制は2ツールが二分する。

OPA Gatekeeper(CNCF Graduated)はOPAポリシーエンジンをKubernetesに統合。Rego言語でポリシーを記述。表現力豊か、あらゆるKubernetesリソースで動作、外部データ(LDAP、Vaultなど)参照可。

Kyverno(CNCF Graduated、2025年卒業)はKubernetesネイティブのポリシーエンジン。YAMLでポリシー記述(Rego学習不要)。Mutate / Validate / Generate / Cleanupの4種類のオペレーション。2026年時点で新規採用はKyverno優勢。

# Kyverno — 未署名イメージを遮断
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  webhookTimeoutSeconds: 30
  rules:
  - name: check-image-signature
    match:
      any:
      - resources:
          kinds:
          - Pod
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/myorg/*"
            issuer: "https://token.actions.githubusercontent.com"
            rekor:
              url: https://rekor.sigstore.dev

同じポリシーをOPA Gatekeeperで書くにはRegoが必要:

package kubernetes.admission

import future.keywords.if

deny contains msg if {
  input.request.kind.kind == "Pod"
  image := input.request.object.spec.containers[_].image
  not signature_valid(image)
  msg := sprintf("image %v lacks valid signature", [image])
}

signature_valid(image) if {
  startswith(image, "ghcr.io/myorg/")
  # ... 外部データまたはSigstore検証呼び出し
}

15. ポリシー実戦 — Pod Security Standards + Kyverno

Kubernetes 1.25でPSP(Pod Security Policy)が削除された後、Pod Security Standards (PSS) + Pod Security Admissionが標準。だがPSSは3つのプリセット(privileged / baseline / restricted)しか提供しないため、細やかなカスタマイズはKyvernoで補うのが2026年のベストプラクティス。

# Kyverno — 5つの核ベースラインを強制
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: pod-security-baseline
spec:
  validationFailureAction: Enforce
  rules:
  - name: disallow-privileged
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "privileged containers are forbidden"
      pattern:
        spec:
          =(securityContext):
            =(privileged): "false"
          containers:
          - name: "*"
            =(securityContext):
              =(privileged): "false"
  - name: disallow-host-namespaces
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "hostNetwork / hostPID / hostIPC are forbidden"
      pattern:
        spec:
          =(hostNetwork): "false"
          =(hostPID): "false"
          =(hostIPC): "false"
  - name: require-non-root
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "containers must run as non-root"
      pattern:
        spec:
          =(securityContext):
            =(runAsNonRoot): true
          containers:
          - name: "*"
            =(securityContext):
              =(runAsNonRoot): true
  - name: disallow-hostpath
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "hostPath volumes are forbidden"
      pattern:
        spec:
          =(volumes):
          - X(hostPath): "null"

16. xzバックドア2024 — 何が防げたか

CVE-2024-3094を時系列で振り返る。

• 2021年: 「Jia Tan」という人物がxz-utilsプロジェクトに登場、2年間信頼を築く
• 2023年末: メンテナーLasse Collinがバーンアウト、Jia Tanにcommitアクセスを付与
• 2024年2月: 5.6.0リリースにバックドア混入(テストファイル内に隠蔽)
• 2024年3月29日: Andres FreundがSSHログイン遅延のデバッグ中に発見

各防御線の効果を評価すると:

結論 — ソーシャルエンジニアリングでメンテナーになられた瞬間にほぼすべての自動化は無力化される。答えはコードレビュー文化+身元検証+ビルド後の振る舞い分析(Falco/Tetragon)の組み合わせ。

17. npmタイポスクワッティング / 依存性混同攻撃

xzとは別に最も頻発するサプライチェーン攻撃はnpm/PyPIタイポスクワッティングとdependency confusion。2024年だけでSonatypeは51万件超の悪意あるパッケージを検出した。

代表的なパターン:

• タイポスクワッティング: loadash(正規はlodash)、colorz(正規はcolors)
• Dependency confusion: 社内NPMレジストリにあるパッケージと同名をpublic npmにより高いバージョンでプッシュ → 内部ビルドがpublicを引いてしまう事件(Alex Birsan、2021年発見)
• アカウント乗っ取り: メンテナーのnpmアカウント奪取 → 正規パッケージに悪意あるバージョンをプッシュ
• Postinstallフック: npm install時に自動実行されるpostinstallスクリプトで悪意あるコードを実行

防御策:

# 1) lockファイルを信頼(package-lock.json / pnpm-lock.yaml)
npm ci  # npm installの代わりに

# 2) postinstallスクリプトを無効化
npm config set ignore-scripts true

# 3) 社内パッケージはscopeを使う(@myorg/foo)
# 4) npm audit signatures — 署名検証
npm audit signatures

# 5) Socket / Snyk / Phylumで事前振る舞い解析

PyPIは2024年からSigstore統合開始、2025年に人気パッケージへattestation義務化。npmは2026年OIDC trusted publishingが標準になりつつある。

18. 韓国の状況 — SBOM義務化の動向

韓国もグローバルな流れに合流中。2024年に科学技術情報通信部がSW供給網セキュリティガイドラインを発表し、SBOMを推奨から段階的義務化へ進めるロードマップを示した。2025年の情報保護産業振興法改正に伴い、公的機関調達SWへのSBOM提出が段階的に義務化され始めた。

国内事例:

• LINE: LINE Engineering Blog(2024年)によれば社内Container RegistryにTrivyを統合し、push時自動スキャン、CRITICAL/HIGHは遮断。イメージ署名はNotary v2を自社運用。
• Kakao: KakaoTalkインフラのコンテナにFalcoを導入(2023年)。2024年にSysdig Secure導入でマルチクラスタ統合管理。
• Coupang: AWS Fargate(Firecrackerベース)中心の運用。自前ビルドシステムでSBOMを自動生成、Snyk ContainerをPRゲートに使用。
• Toss: 2025年Tetragon導入事例を発表(if(kakao)カンファレンス)。PCI-DSSコンテナ隔離に活用。

韓国特有の要素はKISAの**CSAP(Cloud Security Assurance Program)**コンテナセキュリティ項目への準拠が公共クラウド進出のゲートとなっていること。

19. 日本の状況 — IPAガイドライン+Mercari / 楽天事例

日本のIPA(情報処理推進機構)は2024年にコンテナセキュリティガイドライン v2.0を発表。中身はNIST SP 800-190の日本語ローカライズ+金融庁FISCガイドラインへの整合性。SBOMは2025年経済産業省ガイドラインで推奨レベル、2026年は一部公共調達で義務化フェーズへ。

企業事例:

• メルカリ(Mercari): マルチクラスタGKE環境でTrivy + Cosignキーレス署名 + Kyvernoポリシー検証を標準パイプラインとして運用。Mercari Engineering Blog 2025年「Container Security at Scale」シリーズ参照。
• 楽天(Rakuten): 自社データセンター+パブリッククラウドのハイブリッド。Anchore Enterprise + Sysdigの組み合わせ。金融子会社はFIPS 140-3コンプライアンスのためNotary v2を採用。
• DeNA: ゲームコンテナにFalcoを導入、不正行為/ボット検出に活用との事例(2024年SRE Lounge)。
• SmartHR: HR SaaSでGKE + Tetragon(2025年導入)。従業員PIIを扱うコンテナに強隔離が必要。

日本特有のポイントは金融庁FISC安全対策基準。コンテナ隔離等級、ログ保存(原則7年)、外部監査義務が韓国より厳しく、Kata Containers / gVisorなど強隔離ランタイムの採用率が高い。

20. EU CRA (Cyber Resilience Act) — 2025年施行の衝撃

2024年10月EU議会通過、2027年12月完全適用(2026年5月時点でSBOM提出など一部条項が施行中)。主要要件:

• EU域内で販売されるすべてのdigital productに適用(SaaSは除外の可能性 — 協議中)
• 脆弱性処理義務: 発見後直ちに公開 — 24時間以内にENISAへ報告、72時間以内にパッチまたはmitigation案内
• SBOM提供義務: 市場投入時点から5年または製品寿命のうち長い方
• 無断改ざん防止: デジタル署名、セキュアブートなど
• 違反時最大1500万ユーロまたはグローバル売上の2.5%の制裁金

CRAがコンテナセキュリティに及ぼす影響は直接的だ — EU市場でコンテナイメージを販売するならSBOM提出はオプションではない。無料OSSは一定条件(個人1人運用など)で免除されるが、企業がOSSを組み込んで製品化したらその責任は企業に来る。

実務対応 — cosign attach sbomまたはOCIアーティファクトでSBOMをイメージと一緒にプッシュしておけば、EU監査官はcosign download sbom一行で検証可能。

21. CI/CD統合 — GitHub Actionsフルスタック例

エンドツーエンドパイプライン — ビルド → SBOM → スキャン → 署名 → アドミッションポリシー検証まで。

name: secure-build
on:
  push:
    tags: ['v*']

permissions:
  contents: read
  id-token: write   # Sigstore OIDC
  packages: write   # GHCR push
  attestations: write

jobs:
  build-and-sign:
    runs-on: ubuntu-24.04
    steps:
    - uses: actions/checkout@v4
    - uses: docker/setup-buildx-action@v3
    - uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

    # 1) ビルド+プッシュ
    - id: build
      uses: docker/build-push-action@v6
      with:
        context: .
        push: true
        tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}
        provenance: mode=max
        sbom: true

    # 2) Trivyスキャン — CRITICAL 1件でも失敗
    - uses: aquasecurity/trivy-action@master
      with:
        image-ref: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        format: sarif
        output: trivy-results.sarif
        severity: CRITICAL
        exit-code: 1
        ignore-unfixed: true

    # 3) SBOM別途生成(Syft)
    - uses: anchore/sbom-action@v0
      with:
        image: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        format: cyclonedx-json
        output-file: sbom.cdx.json

    # 4) Cosignキーレス署名+SBOM attestation
    - uses: sigstore/cosign-installer@v3
    - run: |
        cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        cosign attest --yes \
          --predicate sbom.cdx.json \
          --type cyclonedx \
          ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

    # 5) SLSA L3 provenance(GitHub OIDC + slsa-github-generator)
    - uses: actions/attest-build-provenance@v1
      with:
        subject-name: ghcr.io/${{ github.repository }}
        subject-digest: ${{ steps.build.outputs.digest }}
        push-to-registry: true

このパイプラインが完走するとGHCRにはイメージ+Cosign署名+SBOM attestation+SLSA provenanceがすべてOCIアーティファクトとして併存する。

22. モニタリング — Falco/Tetragonのアラートをどこに送るか

検知しても人間が見なければ意味がない。アラートルーティング戦略:

• stdout/syslog → Loki/Elastic: 全イベントの永続保存(コンプライアンス)。7年保存義務のある金融は必須。
• 高重要度 → PagerDuty/Opsgenie: 即時呼び出し。ERROR以上。
• 中重要度 → Slack #security-alerts: トリアージ。時間あたり50件を超えるとアラート疲れ — ルールチューニング必要。
• 低重要度 → SIEM (Splunk/Datadog): ルール学習とパターン検知。

Falcosidekick(Falco補助ツール)はアラートを50以上の外部宛先にルーティング — Slack、Teams、PagerDuty、OpenSearch、Splunk、Loki、S3、GCS、AWS SQS、Kafkaなど。

アラート疲れ防止 — Falcoのrules-tuning.yamlでuser_known_*マクロを積極活用し正常な運用動作をホワイトリスト化せよ。最初の1ヶ月はアラート爆発に耐えながらマクロを育てるのが定石。

23. Confidential Containers — TEEベースのメモリ暗号化

2026年のトレンドはConfidential Computing。AMD SEV-SNP、Intel TDX、ARM CCAなどのTEE(Trusted Execution Environment)でコンテナを実行するとメモリがホストOSにすら見えない。CSPの従業員ですらワークロードメモリにアクセス不可な隔離レベル。

**Confidential Containers (CoCo)**プロジェクトはCNCF SandboxからIncubatingへ昇格(2025年)。Kata Containers + TEEの組み合わせ。Azure Confidential Containers、Google Cloud Confidential Space、IBM Cloud HPVSは同じ基盤。

ユースケース — ヘルスケアのPHI、金融のPCIデータ、AIモデル重みの保護。韓国NICE信用評価が2025年に導入事例を発表、日本では野村証券が一部ワークロードに適用。

オーバーヘッドは5-15%だが、H100/MI300Xなどconfidential-aware GPUも登場 — AI推論コンテナに適する。

24. アンチパターン — よくある間違い8つ

運用現場で繰り返し見られる失敗。

1. latestタグの使用: 再現不能+署名検証無効化。常にdigest(@sha256:...)でピン留め。
2. rootユーザーコンテナ: USER nonrootまたはdistroless使用。runAsNonRoot: trueをアドミッションで強制。
3. :空パスワードコンテナイメージ: ベースイメージに空パスワードのアカウントがあるとソーシャルエンジニアリングに脆弱。
4. 機密情報をENVで注入: docker inspectで抽出される。Vault / AWS Secrets Manager + サイドカー、またはSPIFFE。
5. --privilegedの安易な使用: ホストroot同等。本当に必要なcapabilityのみ追加(--cap-add NET_ADMINなど)。
6. CI Runnerにdocker.sockをマウント: ランナー侵害でホストコンテナ全制圧。Sysbox / kaniko / rootless buildahに置き換え。
7. CVEゲートだけで運用: SBOM追跡、署名検証、ランタイムセキュリティがなければ未公開バックドアに無防備。xzの教訓。
8. アラート無視: Falco/Tetragonのアラートを1週間無視すれば次は見なくなる。トリアージSLAなしではセキュリティ基盤は無意味。

25. 今後6-12ヶ月の見通し

• 2026 Q3-Q4: EU CRA部分施行の本格的影響。EU売上があるすべてのSWベンダーがSBOM標準化を加速。
• NIST SP 800-218 SSDF義務化: 米連邦SW調達でSLSA L3相当要求が本格化。
• Rustベースイメージ: glibc/musl依存性をさらに削ったcargo-chef + scratchパターンが拡散。
• Kyverno > OPA Gatekeeper: 新規採用比率での差がさらに広がる見込み。
• eBPF LSM標準化: TetragonタイプのインラインprotectionがFalcoにバックポートされる可能性。
• AIワークロードセキュリティ: モデル重みの完全性、推論コンテナの隔離、prompt injection検知へコンテナセキュリティツールが拡張。
• Sigstore Trusted Publishing: PyPI/npm/RubyGemsすべてがOIDCベースのpublishingに移行 — トークン漏洩事故の激減を期待。

26. 結論 — 自動化はツールではなく文化だ

xzバックドアの最大の教訓はツールではなく運用文化である。メンテナー1人に権限が集中すれば、その人がソーシャルエンジニアリングにやられた瞬間にあらゆる自動化防御が無力化する。答えは:

1. 5層の防御線をすべて運用せよ — スキャン/SBOM/署名/アドミッション/ランタイムのうち1つでも欠ければxz級の事件に晒される
2. アラートは人が見ろ — 自動遮断できない領域は人間が24時間以内にトリアージ
3. 2人レビューを定着させよ — SLSA L4の本質。自動化では作れないセキュリティ層
4. レガシー依存性を定期的に処分せよ — 活動の止まったOSSは次のxz候補
5. コンプライアンスを目的にするな — CRA、SBOM義務化は最低ライン。実セキュリティとコンプライアンスは別問題

ツールは毎年変わる。2026年のTrivy/Tetragon/Cosignが2030年も1位かは分からない。だが上の5つの運用原則はツールがどう変わっても不変だ。

References

• Trivy 公式ドキュメント — https://trivy.dev/
• Aqua Security Trivy GitHub — https://github.com/aquasecurity/trivy
• Anchore Grype — https://github.com/anchore/grype
• Anchore Syft (SBOM) — https://github.com/anchore/syft
• Snyk Container — https://snyk.io/product/container-vulnerability-management/
• Sysdig Secure — https://sysdig.com/products/secure/
• Anchore Enterprise — https://anchore.com/enterprise/
• Sigstore 公式 — https://www.sigstore.dev/
• Cosign GitHub — https://github.com/sigstore/cosign
• SLSA 公式 — https://slsa.dev/
• in-toto attestation — https://in-toto.io/
• CycloneDX 仕様 — https://cyclonedx.org/
• SPDX 仕様 — https://spdx.dev/
• Falco 公式 — https://falco.org/
• Falco docs — https://falco.org/docs/
• Tetragon — https://tetragon.io/
• Isovalent Tetragon blog — https://isovalent.com/blog/post/tetragon-release-1/
• gVisor — https://gvisor.dev/
• Kata Containers — https://katacontainers.io/
• Confidential Containers — https://confidentialcontainers.org/
• OPA Gatekeeper — https://open-policy-agent.github.io/gatekeeper/website/docs/
• Kyverno — https://kyverno.io/
• Distroless イメージ — https://github.com/GoogleContainerTools/distroless
• Chainguard Wolfi — https://github.com/wolfi-dev/
• xz-utils バックドア分析 (Andres Freund) — https://www.openwall.com/lists/oss-security/2024/03/29/4
• NIST SP 800-190 コンテナガイドライン — https://csrc.nist.gov/publications/detail/sp/800-190/final
• EU Cyber Resilience Act — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CISA SBOM 資料 — https://www.cisa.gov/sbom
• Standard Webhooks (参照比較用) — https://www.standardwebhooks.com/
• Notary v2 / Notation CLI — https://notaryproject.dev/
• IPA コンテナセキュリティガイドライン — https://www.ipa.go.jp/security/
• 韓国・科学技術情報通信部 SW供給網セキュリティ — https://www.msit.go.kr/