💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> 「サプライチェーンセキュリティはもはや『チェックボックス・コンプライアンス』ではない。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層の防御線

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

| 段階 | 代表ツール | 何を防ぐか |

|---|---|---|

| イメージスキャン (Build) | Trivy, Grype, Snyk Container, Anchore, Docker Scout | 既知のCVE、設定不備、シークレット漏洩 |

| SBOM生成 (Build) | Syft, Trivy SBOM, Snyk SBOM, CycloneDX-CLI | コンポーネント目録 — 新CVE公開時の影響追跡 |

| 署名&来歴 (CI/CD) | Cosign, Sigstore, Notary v2, in-toto, SLSA | ビルド後の改ざん/偽イメージのプッシュ |

| アドミッションポリシー (Deploy) | OPA Gatekeeper, Kyverno, Polaris, Sigstore policy-controller | 未署名イメージ、rootユーザー、hostPathマウントの遮断 |

| ランタイムセキュリティ (Run) | Falco, Tetragon, Sysdig Secure, Cilium, AppArmor | コンテナエスケープ、不審なsyscall、権限昇格 |

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に統合された無料(一部)ツール。軽量な入口だがエンタープライズ機能は限定的。

| ツール | ライセンス | 強み | 弱み |

|---|---|---|---|

| Snyk Container | 商用 | DevEx最強、ベース推薦 | 高価 |

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より早く情報が上がる。

| DB | 運営 | 強み | 弱み |

|---|---|---|---|

運用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が広く採用された。

| レベル | 要求事項 | 何を防ぐか |

|---|---|---|

| L1 | ビルドプロセス文書化、provenance生成 | 偶発的な手動ビルド |

| L2 | ホスト型ビルドサービス、署名付きprovenance | ビルドマシンの改ざん |

| L3 | 隔離ビルド、検証可能provenance、非改ざん性 | ビルドシステム侵害 |

| L4 | 2人レビュー、再現可能ビルド(目標) | 単独メンテナーによるリスキー変更 |

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**の比較:

| 項目 | Cosign / Sigstore | Notary v2 |

|---|---|---|

| 鍵管理 | キーレス(OIDC)推奨 | ユーザーPKI |

| 透明性ログ | Rekor(必須) | オプション |

| OCI仕様 | tagベース + referrers | 1.1 referrers API |

| 採用 | Kubernetes、CNCF多数 | Azure、AWS Signer |

| 政府認証 | 進行中(FIPS 140-3) | FIPS 140-3保有(Notation CLI) |

実際には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:

handler: runsc

apiVersion: v1

kind: Pod

metadata:

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:

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はカーネル内で完結 — 遅延ゼロ。

| 項目 | Falco | Tetragon |

|---|---|---|

| 発足 | 2016 (Sysdig) | 2022 (Isovalent) |

| ライセンス | Apache 2.0 | Apache 2.0 |

| ガバナンス | CNCF Graduated | CNCF Incubating |

| ポリシー言語 | YAMLルール(独自DSL) | YAML CRD(TracingPolicy) |

| 遮断 | アラートのみ(別ツール連携) | インライン遮断可能 |

| eBPF深度 | syscall中心 | LSM、kprobe、uprobeフル活用 |

| 成熟度 | より実戦経験豊富 | より急速進化 |

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:

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

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検証呼び出し

}

| 項目 | OPA Gatekeeper | Kyverno |

|---|---|---|

| 言語 | Rego(要学習) | YAML(ネイティブ) |

| オペレーション種別 | Validate, Mutate | Validate, Mutate, Generate, Cleanup |

| 外部データ | 豊富(HTTP、LDAP、OCI) | 限定的だが拡大中 |

| イメージ署名検証 | 別controller必要 | 内蔵 |

| 学習コスト | 急 | 緩やか |

| エコシステム | より大きい | 急速に成長 |

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:

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ログイン遅延のデバッグ中に発見

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

| 防御線 | 効果 | 理由 |

|---|---|---|

| Trivy/Grype CVEスキャン | 0 | CVEが存在しなかった — 未公開バックドア |

| SBOM | 一部 | 影響イメージの追跡は可能、事前防御は× |

| Cosign署名 | 0 | メンテナー自身が署名した悪意あるコード |

| SLSA L3 | 0 | ビルドシステム侵害ではない |

| SLSA L4(2人レビュー) | 可能性あり | Jia Tan単独マージを阻止できた可能性 |

| Falco/Tetragon | 潜在的 | sshd子プロセスの異常syscallを検知可能 |

| distroless | 一部 | xz-utilsを含まないイメージは影響なし |

結論 — **ソーシャルエンジニアリングでメンテナーになられた瞬間にほぼすべての自動化は無力化される**。答えはコードレビュー文化+身元検証+ビルド後の振る舞い分析(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 → スキャン → 署名 → アドミッションポリシー検証まで。

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/`