はじめに こんにちは！ マイニフティチームの寺島です。 最近はAIエージェントでの並列開発が活発になってきましたね。 同じリポジトリ内で、一つのタスクをしている間に別のタスクを実施したいことが多々出てくる昨今。 ついに私も git worktree に入門しました。 AIエージェントにバリバリ並列作業をしてもらう前に、機能について知っていると安心してお任せできますので、お勉強をしました。 せっかくの機会なので簡単に、 git worktree についてハンズオン形式でまとめてみましたので、良ければ読んでいただけると嬉しいです。 git worktreeとは Gitで「別の作業領域（ワークスペース）」を構築して並行作業を行う機能は、 git worktree （ワークツリー） と呼ばれます。 git worktree を使えば、1つのリポジトリから複数の作業ディレクトリを別々の場所に作成し、それぞれ異なるブランチを同時に展開しておくことができます。 1. ハンズオン用のリポジトリを作成する まずはベースとなるリポジトリを作成し、最初のコミットを行います。 mkdir git-worktree-demo cd git-worktree-demo git init echo "Initial commit" > README.md git add README.md git commit -m "feat: add initial README" 2. 新機能の開発を始める（メインの作業） 新しい機能（ feature/A ）の開発を開始します。 git checkout -b feature/A echo "WIP: Feature A working..." > feature_a.txt ここで git status を確認すると、 feature_a.txt が未追跡（Untracked）の状態で残っています。 この未コミット状態をキープしたまま 、次の手順に進みます。 3. worktree を使って別ディレクトリで作業する 現在のリポジトリディレクトリの外（一つ上の階層）に、 hotfix 用のディレクトリを作成し、新しいブランチ hotfix/bug-fix を割り当てます。 # 現在のディレクトリの隣に、新しく "hotfix-dir" という作業ツリーを作成する git worktree add ../hotfix-dir -b hotfix/bug-fix main 新しい作業ディレクトリである ../hotfix-dir に対して、 -b オプションで新ブランチ hotfix/bug-fix が main ブランチから作成されます。 作業ツリーの一覧を確認してみましょう。 git worktree list 出力例: /path/to/git-worktree-demo <ハッシュ値> [feature/A] /path/to/hotfix-dir <ハッシュ値> [hotfix/bug-fix] これで、1つのローカルリポジトリを共有しながら、2つのディレクトリで別々のブランチが展開されている状態が作れました。 4. 別タスクを実施する 新しく作られたディレクトリに移動して作業します。 cd ../hotfix-dir echo "Fix critical bug" > fix.txt git add fix.txt git commit -m "fix: resolve critical bug" 5. worktree を片付けて元の作業に戻る 別タスクが終わったので、元のディレクトリに戻り、不要になった worktree を削除します。 # 元のディレクトリに戻る cd ../git-worktree-demo # 使い終わったworktreeを削除する git worktree remove ../hotfix-dir Tips: もしエクスプローラー等で直接ディレクトリを削除してしまった場合は、 git worktree prune コマンドを実行することでGitの管理から綺麗に切り離すことができます。 最後に、元のブランチ（ feature/A ）の状態を確認してみましょう。 git status 先ほど作りかけた feature_a.txt が未追跡のまま、残っていることが確認できると思います。 おわりに 今回のハンズオンのまとめです。 git worktree add <パス> -b <新ブランチ名> <派生元ブランチ> 別ディレクトリに新しい作業ツリーを作成する。 git worktree list 現在展開されている作業ツリーの一覧を確認する。 git worktree remove <パス> 不要になった作業ツリーを安全に削除する。 よい並列開発ライフが送れることを祈っています！

はじめに はじめまして、プラットフォームエンジニアリング本部に所属している徳富( @yannKazu1 )です。 みなさん、サプライチェーン攻撃って気にしてますか？ npm パッケージの乗っ取り（ ua-parser-js 事件 ）、GitHub Actions の改ざん（ tj-actions/changed-files 事件 ）、依存パッケージへのバックドア混入（ xz-utils 事件 ）……。ここ数年、OSS を取り巻くセキュリティの前提がガラッと変わってきています。正直、「いつ・どこから仕掛けられるかわからない」状況です。 しかもサプライチェーン攻撃って、攻撃側のコストが低いわりに被害範囲が広いのが厄介なんですよね。 そんなわけで、ECS Fargate 環境におけるサプライチェーン攻撃対策を整理してみようと思ったのですが、いきなり全部を洗い出そうとしてもカオスになるだけ。何かいいフレームワークはないかな……と探していたところ、Kubernetes の 4C セキュリティモデル（Cloud → Cluster → Container → Code） の考え方がそのまま使えそうだったので、これをベースにチェックシート的に整理してみました。 「うちの環境だとどこが手薄いんだろう？」を考えるときの参考にしてもらえればと思います。 おことわり： これをやれば完璧！というものではないです。あくまで「見通しよく整理するための道具」として 4C モデルを借りているだけなので、実際にどこまでやるかは環境やリスク許容度に応じて取捨選択してください。 整理に使う 2 つの軸 軸 1：4C セキュリティモデル —「どこを守るか」 Kubernetes の公式ドキュメントで紹介されている、クラウドネイティブセキュリティを 4 つの同心円レイヤー で捉えるモデルです。 参考: クラウドネイティブセキュリティの概要 | Kubernetes ┌─────────────────────────────────────────┐ │ Cloud(クラウド基盤) │ │ ┌─────────────────────────────────────┐ │ │ │ Cluster(オーケストレーター) │ │ │ │ ┌─────────────────────────────────┐ │ │ │ │ │ Container(コンテナランタイム) │ │ │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ │ │ Code(アプリケーション) │ │ │ │ │ │ │ └─────────────────────────────┘ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ └─────────────────────────────────────┘ │ └─────────────────────────────────────────┘ ポイントは 各レイヤーが外側のレイヤーの上に構築されている ということ。どれだけアプリのコードを堅牢にしても、基盤レイヤーのセキュリティが低い水準では守りきれません。だからこそ、特定のレイヤーだけに頼るのではなく、すべてのレイヤーを固める 多層防御（Defense in Depth） が基本方針になります。 ECS Fargate への読み替えはこんな感じです。 4C レイヤー K8s での意味 ECS Fargate での対応 サプライチェーン攻撃での主な攻撃面 Cloud クラウド基盤 AWS アカウント・IAM・ネットワーク IAM キー漏洩、ECR への不正 push Cluster オーケストレーター ECS クラスター・CI/CD パイプライン CI/CD アクションの改ざん、パイプライン侵入 Container コンテナランタイム Docker イメージ・Fargate タスク ベースイメージの汚染、OS パッケージへのバックドア混入、実行時の不正プロセス Code アプリケーションコード ソースコード・依存パッケージ パッケージ乗っ取り、typosquatting、悪意ある PR 軸 2：対策の目的 —「何のために守るか」 4C モデルは「どこを守るか」を整理するフレームワークですが、それだけだと対策が偏りがちです。そこでもうひとつ、 「何のために守るか」 という軸を加えてみます。今回は、セキュリティ対策を以下の 4 つの目的に分類して整理してみました。 目的 説明 考え方 🛡 予防（Prevention） 攻撃を未然に防ぐ そもそも悪いものを入れさせない 🔍 検知(Detection) 攻撃や脆弱性を発見する 入り込んだ・紛れ込んだことに気づく 🧱 封じ込め(Containment) 侵入後の被害を最小化する やられても被害を広げさせない 🔎 調査(Investigation) 何が起きたかを追跡する 事後に原因と影響範囲を特定する よくある落とし穴は 「予防」ばかりに意識が向いて、他が手薄になる こと。完璧な予防は不可能なので、入り込まれた後にどう気づいて・どう被害を抑えて・どう調べるか、まで含めて考えるのが多層防御の本質です。 この記事の構成 本記事では 目的（予防・検知・封じ込め・調査）を大項目 にして、それぞれの中で 4C のどのレイヤーに対する対策か を整理していきます。 🛡 予防（Prevention）— そもそも入れさせない 攻撃を未然に防ぐための対策です。「入口を塞ぐ」イメージですね。 Cloud：VPC Endpoint 概要： AWS サービスへの通信をインターネットを経由せずに VPC 内で完結させる。 防げる攻撃： 侵害されたタスクからの外部 AWS アカウントへのデータ持ち出し (Endpoint Policy で自社アカウントに限定) マルウェア感染後の C2 通信・情報送信 (Egress 全遮断下でも AWS サービスは利用可能) 漏洩した IAM 認証情報による外部からの不正アクセス (バケットポリシーで aws:SourceVpce を指定) 設定のポイント： S3 Gateway Endpoint(無料)は必須 ECR、SSM、Secrets Manager、CloudWatch Logs 用の Interface Endpoint を検討 Endpoint Policy で aws:PrincipalAccount を制限 リソース側ポリシーで aws:SourceVpce を指定 Cluster：CI/CD パイプラインのハードニング 概要： GitHub Actions など CI/CD で使うサードパーティアクションを、改ざんされない形で固定する。 防げる攻撃： GitHub Actions の改ざん （tj-actions/changed-files 事件のように、人気アクションのリポジトリが侵害されてタグが書き換えられるケース） バージョンタグの上書きによる 意図しないコードの実行 設定のポイント： GitHub Actions は通常 uses: actions/checkout@v4 のようにタグやブランチで指定しますが、これらは 後から書き換え可能 です。tj-actions/changed-files 事件（2025 年 3 月）では、攻撃者がメンテナーの認証情報を侵害し、既存タグを悪意あるコミットに向け直すことで、汚染されたアクションを使う CI でシークレットがビルドログに書き出されるという被害が広範囲に発生しました。一方、 commit SHA でピンニングしていたユーザーは影響を受けませんでした （侵害期間中に対象 SHA へ更新していなければ）。 対策として、 commit SHA でピンニングする のが推奨されます。 # Before(タグ指定 - 書き換えられる可能性あり) - uses : actions/checkout@v4 # After(commit SHA でピンニング - 改ざんされない) - uses : actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 Dependabot や Renovate Bot で SHA の自動更新を設定 permissions: で各ジョブの GITHUB_TOKEN 権限を最小化 OIDC を使った AWS 認証に切り替え、長期クレデンシャルを廃止 パブリックリポジトリでは特に注意：ビルドログが公開されるため、ログ経由のシークレット漏洩のインパクトが大きい サプライチェーン攻撃との関連： これは Container レイヤーの digest ピンニングと同じ思想です。「同じ名前で違うものを掴まされる」攻撃を防ぐには、暗号学的なハッシュで内容を固定するのが基本になります。 Cluster：Secrets の安全な注入 概要： DB パスワードや API キー等の機密情報を、コードへの直書きではなく SSM Parameter Store や Secrets Manager から注入する。 防げる攻撃： ソースコードやコンテナイメージへのシークレット埋め込み を防止 Git リポジトリの漏洩時に クレデンシャルが直接露出するリスク を排除 KMS 暗号化により、AWS アカウントが侵害されても 暗号化キーなしでは復号不可能 設定のポイント： " secrets ": [ { " name ": " DATABASE_PASSWORD ", " valueFrom ": " /fargate/myapp/database-password " } ] Cluster：ECS Exec の制御 概要： ECS Exec（コンテナへの対話的アクセス）を必要時以外は無効化する。 防げる攻撃： IAM クレデンシャルが漏洩した場合の コンテナへの直接侵入 本番コンテナへの 不正なコマンド実行 設定のポイント： ECS Exec の制御は、サービス （または RunTask 呼び出し）レベル と IAM レベル の二重で行うのが確実です。 enableExecuteCommand はタスク定義のフィールドではなく、サービス（CreateService / UpdateService）または RunTask のパラメータです。 サービス定義（または RunTask 呼び出し）で無効化 ： enableExecuteCommand = false を明示。そもそもサービス側で受け付けない状態にしておく。AWS CLI でも aws ecs update-service --no-enable-execute-command のように切り替え可能です。 IAM で ecs:ExecuteCommand を Deny ：ECS Exec 専用の API なので、これを Deny するのが最も直接的。なお ECS Exec は内部的に SSM Session Manager の通信レイヤー（ssmmessages API）を利用するため、より厳密に制御したい場合は、タスクロールに ssmmessages:* 系の権限が紛れ込んでいないかも確認する 必要時のみ一時的に有効化する運用フロー ：踏み台用の専用サービスを別途用意し、調査時のみそちらを起動する運用が安全。 補足： 後述の封じ込めセクションで紹介する readonlyRootFilesystem: true と ECS Exec は 両立しない 点に注意してください。SSM agent がコンテナファイルシステムへの書き込みを必要とするため、ルートファイルシステムを読み取り専用にすると ECS Exec が動きません(AWS 公式ドキュメントでも明記されています)。本番では readonlyRootFilesystem: true + ECS Exec 無効化、調査用の踏み台サービスでは ECS Exec 有効化、と用途で使い分けるのが現実的です。 Container：ベースイメージの digest ピンニング 概要： Dockerfile のベースイメージ指定を、タグだけでなく digest（SHA256 ハッシュ）で固定する。 防げる攻撃： ベースイメージのタグ上書き攻撃 （同一タグに悪意あるイメージを push） レジストリが侵害された場合の イメージ改ざんの検知 設定例： # Before(タグのみ) FROM ruby:3.3.0-bookworm # After(digest ピンニング) FROM ruby:3.3.0-bookworm@sha256:2e1e76e5b2... 運用のポイント： Dependabot や Renovate Bot で digest の自動更新を設定する digest がまだ付いていないイメージに digest を自動付与する pinning 自体は、現時点では Renovate のほうが運用面で先行 （ pinDigests プリセット）。Dependabot 側でも 2026 年 2 月に PR #14071 が dependabot-core 本体にマージされ、 docker_pin_digests という experiment flag として実装されました。ただし experiment flag は Dependabot サービス側で段階的に展開されるため、GitHub.com の Dependabot で「タグだけのイメージに digest を新規付与する挙動」がデフォルトで使えるかはタイミング次第です（フラグの有効化状況によっては自分の環境で効かないこともある点に注意）。 現時点で「すでに digest 付き」のイメージに対する digest 更新は Dependabot でも問題なくできます。タグだけで運用しているイメージを一括で digest ピン化したい、もしくは version と digest の同時更新・グルーピングや自動マージ条件など細かい制御をしたい場合は、Renovate を選ぶのが堅実です。 サプライチェーン攻撃との関連： Docker Hub のアカウントが侵害されて、同一タグに悪意あるイメージが push されることがあります。digest ピンニングをしておけば、たとえタグが上書きされても意図しないイメージを引っ張ってくることがなくなります。 Container：ECR イミュータブルタグ 概要： ECR リポジトリのタグを上書き不可（IMMUTABLE）に設定する。サプライチェーン攻撃対策の観点では 基本的に有効化しておくべき 設定です。 防げる攻撃： 既存タグへの 悪意あるイメージの上書き CI/CD パイプラインが侵害された際の イメージ差し替え 設定のポイント： ECR のタグ mutability 設定は、 2025 年 7 月 23 日のアップデート で以下の 4 モードに拡張されました。 モード 挙動 MUTABLE すべてのタグを上書き可（従来） IMMUTABLE すべてのタグを上書き不可（従来） MUTABLE_WITH_EXCLUSION デフォルト mutable、特定タグのみ immutable IMMUTABLE_WITH_EXCLUSION デフォルト immutable、特定タグ（例： latest ）のみ mutable これにより、たとえば「 本番用の v1.2.3 のようなセマンティックタグや git SHA タグは IMMUTABLE で固めつつ、 latest だけは上書き可能にしておきたい 」という現実的な要件にも対応できるようになりました。 IMMUTABLE 化（または IMMUTABLE_WITH_EXCLUSION ）すると同じタグでの再 push ができなくなるため、デプロイフローを以下のいずれかに合わせる必要があります。 タグを毎回ユニークにする ： repo:v1.0.1 、 repo:gitsha-abc1234 のように、デプロイのたびに別タグを振る。既存のタグベースのデプロイフローを大きく変えずに済むので導入しやすい。 digest ベースのデプロイに移行する ：ecspresso 等で image: repo:tag → image: repo@sha256:xxxxx に変更。改ざん検知の観点でもより堅牢で、究極的にはこちらが望ましい。 IMMUTABLE_WITH_EXCLUSION を活用する ： latest のような可変運用が必要なタグだけを除外し、それ以外のタグは IMMUTABLE で固める。 まずは (1) のタグユニーク化で IMMUTABLE 化（必要に応じて (3) で latest を除外） から始めて、余裕があれば (2) の digest ベースに進化させていく、というステップ方式が現実的です。 注意： 現在 MUTABLE で運用している場合、デプロイ失敗時のイメージ再 push に依存していないか事前に確認してください。CI のリトライ等でタグの上書きが発生する構成だと、IMMUTABLE 化で詰まります。 Container：イメージ署名（AWS Signer / ECR Managed Signing） 概要： CI でビルドしたイメージに暗号署名を付与し、デプロイ時に署名を検証する。 防げる攻撃： ECR リポジトリが侵害された場合の 未署名イメージのデプロイ CI パイプラインをバイパスした 不正なイメージの注入 「CI でビルドされたイメージと本番で動くイメージが同一である」ことの 暗号学的な保証 実現方法： ECS には EKS の admission controller のような署名検証機構が長らくネイティブには用意されていませんでしたが、近年は AWS 側でも仕組みが整ってきています。代表的なパターンは以下の通り。 (1) 署名フェーズ ： (a) Amazon ECR Managed Signing を使う（2025 年 11 月 21 日 GA、AWS の推奨アプローチ） ：ECR にシグニングルールを登録しておくと、push 時に ECR が AWS Signer を呼んで自動で署名してくれる。クライアント側に Notation を入れる必要がなく、署名キーやその証明書ライフサイクルも AWS が完全マネージドで管理する。新規導入ならまずこちらを検討するのが筋。 (b) 自前で notation sign を実行（manual signing） ：CI のビルドステップでイメージ push 後に Notation CLI + AWS Signer プラグインで署名する。署名タイミングや対象を細かく制御したい場合に選択。プラットフォーム ID は Notation-OCI-SHA384-ECDSA 。 いずれの場合も 署名キー自体は AWS Signer が完全マネージドで管理するため、利用者が KMS キー等を別途用意する必要はありません 。 (2) 検証フェーズ ： (a) ECS Service Lifecycle Hook(PRE_SCALE_UP)で Lambda を呼び、 notation verify を実行 ：ECS のサービスデプロイ時にイメージ署名を検証し、失敗時はデプロイをブロックできる。 現在 AWS が公開している ECS 向け公式パターンであり、 BLOCK_ON_FAILURE (厳格モード)と LOG_ON_FAILURE (監査のみモード)の両方をサポート 。 2025 年 7 月 18 日の ECS ネイティブ Blue/Green デプロイメント GA 以降、PRE_SCALE_UP hook は rolling update 戦略でも利用可能 (rolling update で使えるのは PRE_SCALE_UP のみで、それ以外の hook は Blue/Green 専用)。 (b) EventBridge → Lambda で push 直後に検証 ：監査・アラート用途。Lifecycle Hook と違ってデプロイ自体はブロックできない非同期パターン。 (c) CodePipeline / CI のデプロイ前ステップで notation verify を実行 ：パイプラインの中でブロックする方式。 注意： ECR イミュータブルタグと組み合わせると効果が高まります（タグの差し替え + 署名なしイメージのデプロイの両方を防げる）。Lifecycle Hook ベースの検証はデプロイをブロックできるため、本気の防御として AWS が現在推奨している実装パターンです。実装工数はそれなりにかかるので、リスク許容度と相談して導入判断するのがよいでしょう。まずは EventBridge 経由のアラート運用（監査）から始めて、本格運用で Lifecycle Hook に移行する、というステップでも問題ありません。 EKS との対比（参考）： EKS の場合は Kubernetes admission controller（Kyverno、OPA Gatekeeper、Connaisseur 等）を使って、Pod 起動前に署名を検証するのが定石です。ECS Service Lifecycle Hook はこれに相当する仕組みを ECS 側で提供する位置づけと考えると理解しやすいです。 🔍 検知（Detection）— 入り込んだことに気づく 予防を突破された場合に、異常や脆弱性を発見するための対策です。 Cloud：GuardDuty + ECS Runtime Monitoring 概要： AWS 環境全体の脅威検知サービス。ECS Runtime Monitoring を有効にすると、Fargate タスク内の不審な振る舞いをリアルタイムで検知できる(ECS Fargate 向けは re:Invent 2023 で一般提供開始)。 防げる攻撃： コンテナ内での クリプトマイニングプロセスの実行 C2(Command & Control)サーバーへの通信 コンテナ内での リバースシェルの起動 既知のマルウェアバイナリの実行 設定のポイント： Fargate の場合、セキュリティエージェントは GuardDuty が自動でサイドカーとしてデプロイするため、タスク定義の変更は不要 Organizations の委任管理者から一括有効化が可能 サプライチェーン攻撃との関連： 汚染された npm パッケージや gem が実行時にこっそりマイニングスクリプトを起動したり、バックドアが C2 サーバーに接続したり……といったケースをリアルタイムで検知してくれます。「入り込まれた後」の最後の砦ですね。 Cloud：Security Hub（セキュリティポスチャ管理） 概要： AWS Foundational Security Best Practices (FSBP) などのセキュリティ標準に基づき、設定の逸脱を検出する。 防げる攻撃： セキュリティグループの過剰な公開、暗号化の欠如など、 設定ミスに起因する攻撃面の拡大 を防止 Inspector や GuardDuty の検出結果を一元的に集約し、 見逃しを減らす Container：イメージスキャン(CI + ECR Enhanced Scanning) 概要： コンテナイメージに含まれる脆弱性を、CI のビルド時とレジストリの両方でスキャンする。サプライチェーン攻撃対策の観点では OS パッケージレイヤーへの攻撃（xz-utils 事件のような）を捕まえるための要 となる対策です。 防げる攻撃： 既知の脆弱性を持つ OS パッケージ・言語ライブラリ がプロダクションに到達するのを検知 xz-utils 事件のように OS パッケージレベルでバックドアが混入したケース (CVE 公開後)を検知 アプリ側の依存パッケージマネージャー（Bundler / npm 等）では拾えない、 OS レイヤーの脆弱性 をカバー サプライチェーン防御の基本は 複数のポイントでチェックする ことです。CI でのビルド時スキャンとレジストリでの継続スキャンを組み合わせて、異なるタイミングで網をかけるのが効果的です。 CI ビルド時スキャン → レジストリスキャン(継続) → ランタイム監視 (Trivy / Inspector 等) (ECR Enhanced Scanning) (GuardDuty) デプロイ前にブロック 新規 CVE も自動で再スキャン 実行時の異常検知 CI でのスキャン 代表的なアプローチは大きく 2 系統あります。 (a) OSS スキャナ（Trivy / Grype 等） docker build 後にスキャンを実行し、脆弱性が閾値を超えたらデプロイをブロック セットアップが軽く、外部 API への依存もないので導入ハードルが低い Dockerfile の Linting（hadolint 等）も合わせて入れると効果的 (b) Amazon Inspector SBOM Generator (sbomgen) + Inspector Scan API AWS 公式アプローチ。 sbomgen でイメージから CycloneDX 形式の SBOM を生成し、Inspector Scan API に投げて脆弱性スキャンを実行 GitHub Actions なら AWS 公式の aws-actions/vulnerability-scan-github-action-for-amazon-inspector が使える。SBOM 生成からスキャン、結果のサマリー表示までワンステップで完結 Jenkins 用のプラグインも公式提供あり Inspector を既に有効化している環境なら、ECR Enhanced Scanning と 同じ脆弱性データベース・同じ判定基準 で CI 段階から検査できるのがメリット 生成された SBOM をアーティファクトとして保存しておけば、調査セクションで触れる SBOM 管理にもそのまま流用可能 CI で push 前に止められる のがこのレイヤーの最大の価値（シフトレフト）です。AWS 中心の構成なら (b) が一気通貫で扱いやすく、ツール選択の自由度を取りたいなら (a) という選び方になります。 ECR Enhanced Scanning（Inspector 統合） ECR push 時 + 新規 CVE 公開時に自動で再スキャン（ CONTINUOUS_SCAN ） OS パッケージに加えて言語ライブラリも対象 Security Hub にネイティブ統合されるため、検出結果を一元管理できる Basic Scan Enhanced Scan (Inspector) 対象 OS パッケージのみ OS パッケージ + 言語ライブラリ(gem, npm, pip 等) スキャン頻度 push 時のみ push 時 + 新規 CVE 公開時(CONTINUOUS_SCAN) Security Hub 統合 なし あり 組織一括管理 なし あり(Organizations 委任管理者から) xz-utils 事件との関連： xz-utilsのような OS パッケージレベルのバックドアは、アプリケーションの依存パッケージマネージャー（Bundler / npm）レベルの SCA では検知できません。 コンテナイメージスキャンの OS パッケージレイヤー で拾うのが正しい守備範囲です。なお、xz-utils のバックドアはビルドプロセス中に難読化されたペイロードを段階的に展開する極めて巧妙な手口で、CVE 公開「前」の検知は実質的に困難でした。だからこそ、CVE 公開後にどれだけ早く対応できるかが勝負になります( CONTINUOUS_SCAN のような新規 CVE への自動再スキャンが効いてくるのはこのため)。 Code：SCA（ソフトウェア構成分析） 概要： アプリケーションが依存するパッケージ（Bundler の gem、npm のパッケージ等）の既知脆弱性および悪意あるバージョンへの依存を検出し、更新を促す。 アプリケーション依存パッケージレイヤーのサプライチェーン攻撃対策の中核 となる対策です。 防げる攻撃： 既知の脆弱性を持つアプリ依存パッケージ への依存を早期発見 パッケージの乗っ取り （ua-parser-js 事件、event-stream 事件のような）で注入された悪意あるバージョンへの自動更新を抑止 typosquatting （正規パッケージに似た名前の悪意あるパッケージ）への気づき ツール例： Dependabot（GitHub ネイティブ、Bundler / npm / Docker 対応） Renovate Bot（digest ピン対応、細かい設定が可能） GitHub Advanced Security の Dependency Review 設定のポイント： パッケージマネージャー（Bundler、npm）と GitHub Actions の両方を対象に daily または weekly でスキャン versioning-strategy の設定で意図しないメジャーバージョンアップを防止（npm なら lockfile-only 、Bundler なら lockfile-only 相当の制約をかける） 更新を即座に取り込まない ：新バージョンに悪意が混入していた場合に備え、リリースから一定期間（例：3〜7 日）寝かせてからマージするポリシーも検討に値する 守備範囲の整理： SCA は アプリの依存パッケージマネージャー（Bundler / npm 等）の領域 が対象です。OS パッケージ（apt / yum / apk）レベルの脆弱性は SCA ではなく、前述のコンテナイメージスキャンが守備範囲になります。 ua-parser-js のような npm パッケージ乗っ取りは SCA、xz-utils のような OS パッケージへのバックドア混入はイメージスキャン、と分けて考えるとスッキリします。 Code：SAST（静的アプリケーションセキュリティテスト） 概要： ソースコードを静的に解析し、セキュリティ上の問題を検出する。 位置づけの注意： SAST はサプライチェーン攻撃そのものへの直接対策ではなく、 自前コードの脆弱性検出ツール です。ただし、攻撃者が悪意ある PR を送り込んできた場合（社外コントリビューターからの PR や、内部アカウントが乗っ取られた場合）に、危険なコードパターンを検出できる可能性があります。多層防御の一環として位置づけてください。 防げる攻撃： SQL インジェクション、XSS、CSRF 等の コーディングレベルの脆弱性 フレームワーク固有の危険なパターン（Rails なら Brakeman、Node.js なら ESLint Security Plugin 等） 悪意ある PR に含まれる 明らかに怪しいコードパターン 設定のポイント： CI で全 PR に対して実行し、マージ前に検出 言語・フレームワーク固有のツールを選定 🧱 封じ込め(Containment)— やられても被害を広げさせない 予防も検知もすり抜けて侵入された場合に、被害の範囲を最小限にするための対策です。「入られた前提」で考えるのがポイント。 Cloud：ネットワーク制御（Egress 制限） 概要： コンテナからのアウトバウンド通信を必要最小限に制限する。侵害が起きた後にデータ持ち出しや C2 通信を成立させにくくする、封じ込めとしての効果が大きい。 防げる攻撃： ランタイム侵害後の C2 サーバーへの通信をネットワークレベルで遮断 悪意あるパッケージや侵害されたコンテナによる外部へのデータ送信をブロック xz-utils 事件のようなバックドアが仮にコンテナ内に入り込んでも、外部との通信路を断つことで攻撃者の活動を阻害 設定のポイント： AWS Network Firewall：FQDN ベースのアウトバウンド許可リスト方式で必要なドメインのみ通す Route 53 DNS Firewall：悪意あるドメインへの DNS クエリをブロック Security Group：NAT Gateway 経由のアウトバウンドを最小化し、不要なポート・宛先を塞ぐ Cluster：IAM ロール分離（タスクロール / 実行ロール） 概要： ECS の実行ロール（ECR pull、ログ出力等）とタスクロール（アプリケーションが使う権限）を分離する。最小権限の原則そのものなので予防の性質も持ちますが、真価を発揮するのは侵害が起きた後—— 横移動の範囲を制限する封じ込めとしての効果が大きい ため、ここで扱います。 防げる攻撃： アプリケーションが侵害された場合でも、 ECR へのイメージ push や他タスクへの影響を防止 権限の最小化により、 ラテラルムーブメント（横移動）の範囲を制限 設定のポイント： 実行ロール ：ECR pull、CloudWatch Logs、SSM パラメータ取得のみ タスクロール ：アプリケーションが実際に必要とする権限のみ ssm:GetParameters の Resource は ではなくパラメータパス(例： /fargate/myapp/* )で制限 タスクロールに ecr:PutImage 等の書き込み権限が紛れ込んでいないか定期確認 Container：コンテナハードニング コンテナが侵害された後の被害を最小限にするための設定群です。まさに「封じ込め」の代表格。 readonlyRootFilesystem 概要： コンテナのルートファイルシステムを読み取り専用にする。 防げる攻撃： コンテナ侵害時の マルウェアのファイルシステムへの書き込み・永続化 攻撃ツールの 追加ダウンロードと配置 Web シェルの設置 設定例： { " containerDefinitions ": [ { " name ": " app ", " readonlyRootFilesystem ": true , " mountPoints ": [ { " sourceVolume ": " tmp ", " containerPath ": " /tmp " } , { " sourceVolume ": " app-tmp ", " containerPath ": " /app/tmp " } ] } ] , " volumes ": [ { " name ": " tmp " } , { " name ": " app-tmp " } ] } 注意 1： アプリケーションによっては /tmp や /app/tmp 、 /app/log 等への書き込みが必要です。tmpfs ボリュームをマウントして書き込み先を確保してください。 注意 2： readonlyRootFilesystem: true は ECS Exec と両立しません 。SSM agent がコンテナファイルシステムへの書き込みを必要とするためです（ AWS 公式ドキュメント で明記）。本番タスクは readonlyRootFilesystem: true + ECS Exec 無効化、調査用の踏み台サービスは readonlyRootFilesystem: false + ECS Exec 有効化、と用途で分けるのが現実的です。 Linux capabilities の DROP ALL 概要： コンテナに付与される Linux capabilities をすべて削除する。 防げる攻撃： コンテナ内からの 不要な特権操作 を制限 権限昇格(setuid バイナリ経由、カーネル脆弱性等)を試みた際の 被害を抑制 USER ディレクティブが何らかの理由で無視・上書きされた場合の 保険 設定例： { " linuxParameters ": { " initProcessEnabled ": true , " capabilities ": { " drop ": [ " ALL " ] } } } 補足： Fargate では元々 capability の add は不可でしたが、プラットフォームバージョン 1.4.0 以降、 SYS_PTRACE の 1 つだけは追加可能 になりました（Sysdig Falco のような観測ツール用途のために 2020 年に解禁された経緯がある）。一方、 drop は問題なく可能 です。EC2 launch type ではすべての capability が利用できますが、Fargate で add できるのは依然として SYS_PTRACE のみという制約があります。非 root で実行していれば実質的な効果は限定的ですが、多層防御（Defense in Depth）の観点から「保険として入れておく」温度感で設定しておくと安心です。 非 root 実行 概要： コンテナプロセスを root 以外のユーザーで実行する。 防げる攻撃： コンテナ侵害時の ホストへのエスケープリスクを低減 ファイルシステムやプロセスへの不正操作の範囲を制限 設定方法： Dockerfile で USER app:1000 のように非 root ユーザーを指定 サイドカー（fluent-bit 等）も可能な限り非 root 化 🔎 調査（Investigation）— 何が起きたかを追える状態にする インシデントが起きた後に「何が起きたか」「影響範囲はどこまでか」を追跡するための対策です。地味ですが、ここが抜けていると事後対応でめちゃくちゃ苦労します。 Cloud：CloudTrail（監査ログ） 概要： AWS API コールの監査ログを記録・保全する。 防げる攻撃・実現できること： IAM クレデンシャルが漏洩した場合の 事後調査(フォレンジック) が可能になる 「誰が・いつ・どの API を叩いたか」を追跡でき、不正な ECR push や IAM 変更を特定できる ECS のコントロールプレーン操作（クラスター / タスク定義 / サービスの作成・更新・削除など）も AWS API コール経由で行われるため CloudTrail でカバーされる 。Cluster 層で「誰が悪意あるタスク定義を登録したか」「サービスが書き換えられたのはいつか」を追えるのはここ S3 Object Lock でログの改ざん・削除を防止 CloudTrail ログファイルの整合性の検証（CloudTrail log file integrity validation）でログ自体が改ざん・削除されていないことを事後検証できる 。CloudTrail が 1 時間ごとに、その間に配信されたログファイルのハッシュを含むダイジェストファイルを RSA で署名して S3 に配置するので、 aws cloudtrail validate-logs で「保管されているログが配信時のものと一致するか」を検証できる 設定のポイント： 組織トレイルでマルチリージョン・全管理イベントを記録 S3 Object Lock(GOVERNANCE モード以上)でログの不変性を担保 ログファイルの検証（Log file validation）を有効化 （コンソール作成時のオプション、CLI なら --enable-log-file-validation ）。S3 Object Lock が「改ざんさせない」予防策、ログファイルの整合性の検証が「改ざんされていないことを示す」検出策で、両方揃えると証跡としての信頼性が一段上がる Advanced Event Selectors で S3 データイベントも記録 サプライチェーン攻撃との関連： たとえば攻撃者が CI/CD の認証情報を奪って ECR にイメージを push した場合、CloudTrail がなければ「いつ・どのアカウントから push されたか」すら追えません。同様に、奪った認証情報で RegisterTaskDefinition や UpdateService を叩かれた場合も、CloudTrail があれば Cluster 層での改ざんを追跡できます。防御だけでなく「何が起きたか調べられる状態にしておく」のも大事です。 Cloud：VPC フローログ / DNS クエリログ（ネットワークレベルの追跡） 概要： VPC 内の通信メタデータと DNS 名前解決を記録し、「どこから・どこへ・何が通信したか」を追跡可能にする。 実現できること： 侵害されたタスクが どこに通信していたか （C2 サーバー、不審な外部エンドポイント、想定外の内部リソース）を特定できる VPC フローログは ECS タスクの ENI 単位で取得可能で、 タスクごとの通信を追跡 できる（ ECS 向けの VPC フローログ機能 ） VPC フローログと Route 53 Resolver クエリログを組み合わせて分析することで、「いつ・どのドメインに対して通信したか」まで踏み込んだ調査ができる 。フローログ単体だと宛先 IP しか分からず、CDN やクラウドサービス相手だと「結局どこと話していたのか」が判然としない。クエリログで名前解決の履歴を突き合わせることで、IP → ドメインのマッピングが復元でき、不審な通信先の正体を特定しやすくなる マルウェアが DGA（ドメイン生成アルゴリズム）で生成したドメインへ問い合わせた痕跡など、フローログだけでは見えない挙動も DNS クエリログ側で捕捉できる 設定のポイント： VPC フローログは S3 / CloudWatch Logs に出力。長期保管なら S3 + Object Lock カスタムフォーマットで pkt-srcaddr / pkt-dstaddr を含めると、NAT 越しでも実際の送信元・宛先が分かる Route 53 Resolver クエリログを VPC に紐づけておけば、タスクからの DNS 問い合わせも記録される サプライチェーン攻撃との関連： 悪意ある依存パッケージが侵入した場合、最終的に外部 C2 への通信を試みるケースが多いです。CloudTrail は API コールの記録なので、こうした データプレーン上の通信 までは追えません。VPC フローログ + DNS クエリログを揃えて組み合わせ分析できる状態にしておけば、「侵害されたタスクがどのドメインを名前解決し、その IP に対して実際にどれだけのトラフィックを流したか」まで一連の流れで再構成でき、情報流出先や C2 ドメインの特定が一気に現実的になります。 Code：SBOM（ソフトウェア部品表） 概要： アプリケーションが依存するすべてのパッケージとそのバージョンを一覧化する。 実現できること： インシデント発生時に 「何のバージョンの何が動いていたか」 を即座に特定 新たな CVE が公開された際に 影響範囲を迅速に判断 xz-utils 事件のように 依存関係に紛れ込んだバックドア が後から発覚した場合の影響調査を効率化 実現方法： CI 段階で sbomgen を使う：検知セクションで触れた aws-actions/vulnerability-scan-github-action-for-amazon-inspector 等は、副産物として CycloneDX 形式の SBOM を出力する。脆弱性スキャンと SBOM 保存が同時にできるので一石二鳥 Amazon Inspector の SBOM エクスポート機能 を使うと、Inspector でスキャン済みのリソース（ECR イメージ等）の SBOM を CycloneDX または SPDX 形式で S3 にエクスポート できる。リアルタイム生成ではなく一括エクスポート方式なので、定期実行ジョブとして仕込んでおくのが現実的 いずれの場合も、イメージのバージョン（できれば digest）と SBOM を紐づけて保管 しておくのがポイント。インシデント時に「あの時動いていたバージョン」の SBOM をすぐ参照できるようにする サプライチェーン攻撃との関連： 「うちで動いてるイメージに xz-utils の脆弱バージョンって入ってたっけ？」を即答できる状態を作っておく、というのが SBOM の本質です。インシデント時に手作業で全イメージを掘り返すのは現実的ではないので、平時から仕組み化しておきましょう。SBOM は OS パッケージとアプリ依存パッケージの両方をカバーするため、「SCA で見える範囲」と「イメージスキャンで見える範囲」を横断して影響調査できる のが強みです まとめ 正直、セキュリティ対策って「どこまでやればいいの？」が永遠の問いだと思うんですが、まずはこのマトリクスで現状を棚卸しして「ここが手薄いな」と見えるようにするだけでも一歩前進です。 この記事が、ECS Fargate 環境のサプライチェーン攻撃対策を考える際のチェックシートとして使ってもらえれば嬉しいです。 参考資料 クラウドネイティブセキュリティの概要 | Kubernetes Amazon GuardDuty ECS Runtime Monitoring Amazon Inspector ECR scanning Amazon Inspector SBOM Generator (sbomgen) Integrating Amazon Inspector scans into your CI/CD pipeline aws-actions/vulnerability-scan-github-action-for-amazon-inspector Amazon Inspector SBOM export AWS Signer for container images Streamline container image signatures with Amazon ECR managed signing Amazon ECR now supports managed container image signing (2025-11-21) Extending deployment pipelines with Amazon ECS blue green deployments and lifecycle hooks Container image signing and verification using AWS Signer for Amazon ECS and AWS Fargate Amazon ECR now supports exceptions to tag immutability (2025-07-23) Preventing image tags from being overwritten in Amazon ECR ECS タスク定義 - linuxParameters KernelCapabilities - Amazon ECS Fargate security best practices in Amazon ECS Monitor Amazon ECS containers with ECS Exec (readonlyRootFilesystem との非互換について) Security hardening for GitHub Actions GHSA-mrrh-fwg8-r2c3: tj-actions/changed-files supply chain compromise CISA: Supply Chain Compromise of Third-Party tj-actions/changed-files (CVE-2025-30066) and reviewdog/action-setup (CVE-2025-30154) CVE-2024-3094: XZ Utils Backdoor Renovate Docker Presets Dependabot: Add digest pinning when updating Docker image tags (#14065 / PR #14071, 2026-02-04 マージ済み)

はい、こんにちはー！クロスイノベーション本部 サイバーセキュリティテクノロジーセンターの福山です。 昨年あたりから、ソフトウェア脆弱性報告件数の増加やサプライチェーン攻撃のニュースが目立つようになりました。 そこで今回は脆弱性管理とソフトウェアサプライチェーンの現状を把握すべく、関連テーマにフォーカスしたセキュリティカンファレンス「VulnCon」にバーチャル参加しましたので、本稿にレポートとしてまとめます。 VulnConとは 1. NIST's National Vulnerability Database Update and the Vulnerability Enrichment Ecosystem 2. Vulnrichment Playground 3. Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game? 4. How to Answer "What's Affected?" in Open Source 5. Identifying Exploited and Likely-to-Be-Exploited Vulnerabilities 6. Taming the Scanner Storm: How VEX Brings Context to Vulnerability Data 7. Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence 8. Lessons From NPM's Dark Side: Preventing the Next Shai-Hulud まとめ VulnConとは VulnConとはCVEプログラムやFIRSTが中心となって主催する「脆弱性管理に特化した国際カンファレンス」です。 第1回開催は2024年と比較的新しいカンファレンスであり、今年は米国アリゾナ州スコッツデールで開催されました。 https://www.first.org/conference/vulncon26/ VulnConは、脆弱性管理とサイバーセキュリティ分野の専門家が一堂に会し、意見交換などを行い、具体的な成果の創出を目指す場となっています。 今回、VulnCon 2026（現地時間：2026年4月13日～4月16日開催）をリモートで視聴（参加費用 $100）し、筆者が注目した8つのセッションを紹介します。 本記事では各セッション内容をもとに、脆弱性管理およびサプライチェーンセキュリティの観点から重要なポイントを整理しました。 なお、本記事は講演者の発言内容に基づく書き起こしであり、内容は「TLP:CLEAR」のみです。 1. NIST's National Vulnerability Database Update and the Vulnerability Enrichment Ecosystem 発表：NIST NVD NVDの役割 CVEに対してNVDは追加メタデータ（CPE・CVSS・CWE・参照タグ）を提供する「バウンダリーオブジェクト」として機能 CNAは2016年以降独自公開が可能になり、現在502のCNAが存在 スケールの問題：NVDが直面する現状 CVEの増加数が過去最大レベルに達しており、現行の手動プロセスでは追いつかない CPE割り当てに分析時間の半分以上を消費（LLMプロジェクトやGitHubベースのソフトウェアの急増が負荷を増大） 大規模な未処理バックログが蓄積 NVDの新しい優先度付けアプローチ（リスクベースへの転換） CISA KEVリスト掲載CVE：1営業日以内にエンリッチ（付加情報の付与） 米国連邦政府ソフトウェアに関連するCVE 大統領令14208号で定義されたクリティカルソフトウェアのCVE リクエストベースでの対応も受け付け（対応は可能な範囲で実施） CVSSスコアの方針変更 既にスコアを持つCVEには重複スコアを付与しない（Gap Fillingの正式化） アナリストが矛盾を発見した場合は再評価の可能性あり ※Gap Filling：2025年から暫定導入され、CNAから提出されたCVSSおよびCWEデータを再検証せずに、一時的に受け入れる方針のこと バックログの整理 「deferred」ステータスを「not scheduled」に改名 2026年3月1日以前の古いバックログは原則「not scheduled」に移行 修正されたCVEの再エンリッチは原則行わず（リクエストがあれば対応） 自動化への取り組み LLM/AIを活用した分析自動化を小チームで研究中：完成次第オープンソースとして公開予定 RPAによる反復作業の自動化も並行して検討 CPE管理のフェデレーション化（CNAや作業グループと協議中） 2. Vulnrichment Playground 発表： CISA、Tharros Labs Vulnrichmentとは CISAが連邦政府機関（FCEB）や重要インフラ保護のために行っている脆弱性分析を広く公開する取り組み CVEのADP（Authorized Data Publisher）コンテナとして提供、GitHubリポジトリからも取得可能 毎年約2,000件以上のCVD（協調的脆弱性開示）ケースを処理する中で得た大規模な分析知見が元になっている Vulnrichmentが提供するデータ SSVC（Stakeholder Specific Vulnerability Categorization）：全新規CVEにスコアリング KEVフラグ：既知の脆弱性悪用カタログへの掲載有無 CVSS・CWE：CNA未提供分のバックフィル（CNAが既に提供している場合は上書きしない） 参照タグ：パッチ・アドバイザリ等の分類 2年目の最大の変化：CPEの廃止 当初CPEの付与も実験的に行っていたが、分析時間の2/3をCPE作成に費やしていることが判明 利用者からの「CPEよりSSVC・KEV・CWEのカバレッジを広げてほしい」という声を受けて廃止 CPE廃止によってリソースを再配分し、全新規CVEへの完全エンリッチメントが可能になった 「Playground」の本質：本番環境での実験 KEVは拘束力のある運用指令（BOD）に紐づいており変更コストが高い。Vulnrichmentは低リスクで実験できる場として設計されている 「追加するだけでなく、やめることも重要」という姿勢：CPE廃止がその実践例 Linuxカーネルから「上流カーネル脆弱性のCVSSスコアリングをやめてほしい」という要望（GitHub Issue #262）も公開の場で議論中 Pandoc CVEを使った実践例（CVE記録がどう変化するか） 当初：記述不明確、影響範囲（affected）が「N/A」、誤った参照リンク Vulnrichmentが同日中にCVSS・SSVCを追加 数ヶ月後：参照を修正、SSVCの技術的影響を誤入力→後日修正 実験的介入：CISAが直接Pandocの開発者と議論・検証を行ったうえで書き直す（通常スコープ外） 今後の実験候補：CVE間の関係性の表現 現在は記述文の最終行に「他のCVEとの関連」を自然言語で書くしかない 「CVE同士の関係性を機械可読な形で表現できないか」をVulnrichmentで実験したい（スキーマ変更の前段として） Pandocの例：外部ツールの呼び出し時に別のSSRF脆弱性が発生→関係性が人間にはわかるが機械には処理できない Supplier ADP（SADP）パイロットへの言及 CNA自身が「自社製品でこのCVEは影響なし」というVEX的な情報をADPコンテナとして追記できる仕組みのパイロット 例：Pandocを組み込んだ自社Webアプリが --sandbox など安全な方法でPandocを呼び出しており影響を受けない場合、（提供元がCNAであれば）その旨をADPコンテナとして「影響なし」と追記できる。 参考： https://github.com/CVEProject/sadp-pilot Vulnrichmentのデータ品質・透明性について CVEプログラムのレコード・NVD・Vulnrichmentの3つを信頼性で順位付けするのは難しい 「GitHub上で問題提起→議論→修正」という透明なプロセスが品質の担保 CVSSだけで脆弱性を優先度付けするのは不十分であり、SSVCのようなコンテキスト情報との組み合わせが重要 3. Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game? パネルディスカッション： Telos Labs、VulnCheck、HeroDevs、GitHub 議論の前提 CVE CNA Rules 4.1.8 / 4.1.9：一般的な目的で故意に作成された悪意のあるコードはCVE対象外。ただし、トロイの木馬、バックドア、または類似のサプライチェーンの侵害など、悪意のある形に改変された製品は、脆弱性であると判断される可能性がある。 OSVやOpenSSFのmalicious-packagesリポジトリなど代替はあるが、エコシステム全体での標準化や運用の成熟はまだ発展途上 ケース1：XZ Utils（CVE-2024-3094）—バックドア埋め込み Red Hatがバックドアを悪意ある改変済み正規コードとしてCVEを発行 CVEがあったことで、既存の脆弱性管理パイプラインがすぐに対応できた CVEなしでは「どのXZ Utilsの問題か」の識別子がなく、情報伝達が混乱していた可能性 ケース2：tj-actions（CVE-2025-30066）—GitHubアクションの侵害 メンテナーのアカウントがロックアウトされた状態でMITREがCVEを発行 メンテナーが機能停止しても、他のCNA（この例ではMITRE）がCVE発行で通知を前に進められる可能性が示された CVEがあったことで既存ワークフローへの統合が即座に可能 ケース3：Shai-Hulud—npmワームキャンペーン npmのマルウェア削除処理がCVEなしで機能し、GHSAが公開されnpm auditで警告 CVEを使わなくても npm エコシステム（GHSA/npm audit）が機能した ただしCVEシステムにはキャンペーン全体を関連付けるメカニズムが存在しない（記述に書くしかない） ケース4：Trivy侵害（CVE-2026-33634） GitHubがTrivy向けCVEを発行、下流のLightLLMとTelnyxは個別アドバイザリを取得 パッケージマネージャーをまたがる侵害（Go＋PyPI）でのCVE運用の課題を浮き彫りに CVEが最善の方法か？ 「CVEは25年前の設計思想で動いており、今でも機能している。だが完璧ではない」 キャンペーン全体を一つのIDで追跡したい場合と、個別パッケージごとにIDが必要な場合は矛盾する CVEの増発は対応チームの負荷増大を招く（10件のCVEは1件の10倍の事務作業） 「IDが多すぎることは問題ではないが、それらを関連付けられないことが問題」（現行CVEにそのメカニズムなし） 4. How to Answer "What's Affected?" in Open Source 発表： Google CVEプログラムの課題 1999年は321件 → 現在は10分に1件ペース 構造化されていないテキストが多く、自動マッチングが困難 NVDのCPE付与の遅延により手動処理が必要な状況が続いている OSV（Open Source Vulnerability）スキーマの設計思想 機械可読な形式でオープンソースの脆弱性を記述 introduced （脆弱性の混入時点）・ fixed （修正が入った時点）・ last_affected （影響を受ける最終点）イベントで範囲を定義 OSVの設計がCVE5.0スキーマにおけるバージョン範囲導入に影響した バージョン範囲の複雑さ（LTSブランチ問題） 「1.xで導入→2.2.8で修正→3.0で再導入」のような複数ブランチは単純な線形バージョンでは表現しづらい コミットの差分（diff）をハッシュ化した patch-id を使うことで、チェリーピックされた修正を自動検出できる Gitは本質的な順序関係を持つため、エコシステム固有のバージョン比較ロジックに頼らずに済む 「影響あり」判定のルール 導入コミットから現在のコミットへ、修正コミットを経由しないパスが存在する場合に影響あり マージコミットの扱い：修正ブランチ取り込みでも履歴次第で安全性が変わる。判断には“introduced→当該commit”の経路にfixedを含むか、曖昧なら影響あり寄りに倒す。 introduced: 0 （最初のバージョンから脆弱）の際、Gitの複数ルート（subtreeなど）への対処も明示 データソースの種類 エコシステム直接提供（crates.io、GoなどはOSVフォーマットで直接提供、関数レベルの情報も含む） GitHub Security Advisory（GHSA）経由でMaven・npmの情報を補完 CVE/NVDからの変換：バージョンタグとGitコミットを照合して範囲を推定（ただし修正コミットではなくリリースコミットを辿りがちで限界もある） ここから学べること CNAとしてGitコミットハッシュでの脆弱性レポート提供を強く推奨 ツール（VEX・到達可能性解析・静的解析）と組み合わせて「自分のプロジェクトで実際に影響を受けるか」をさらに絞り込める 5. Identifying Exploited and Likely-to-Be-Exploited Vulnerabilities 発表： VulnCheck VulnCheckのCNA活動の3本柱 Report of Vulnerability Service：外部研究者から脆弱性報告を受け付け、CVE発行まで無償でサポート 脆弱性研究・CVD調整：サードパーティとの調整、監査、CVEアサイン Initial Accessチーム：エクスプロイト開発、検知アーティファクト作成（実際に脆弱なコンテナを本番インターネットに公開して攻撃トラフィックを確認） VulnCheck独自KEVの定義と実態 「公開情報として悪用報告があるもの」または「VulnCheckが観測したもの」すべてをKEVとして扱う（CISAより広い定義） 2025年の悪用確認済み脆弱性のうち約28%が開示日当日以前に悪用証拠あり AIの普及によりこのタイムラインがさらに短縮される懸念 CVE未割当の悪用脆弱性の発見：Shadow Serverとの連携 Shadow Serverのシンクホール（悪用検知シグネチャ）を分析→CVEが存在しない状態で長年悪用されていた脆弱性を約50件発見、CVEアサイン 実例：2016年から公開されていたD-LinkのDSLモデムの脆弱性→2025年まで未割当→CVEアサイン後にCISA KEVへ掲載 「CVEがない＝リスクがない」ではなく、単に見えていないだけ Metasploitモジュールの監査 Metasploitに存在するエクスプロイトモジュールとCVEの紐付けを全件監査 数百件のモジュールにCVEが未割当→うち約200件はCNA管轄内でCVEアサインが可能 Moore's Lawの進化版：「カジュアルな攻撃者の能力向上速度≒AIの進化速度」になりつつある BlackHat/Bostonのチャットログ例：脅威アクターがMetasploitをインストールし多数のモジュールを活用 製品セキュリティアドバイザリの活用 Microsoft MSRCのような機械可読フォーマットで悪用インジケータを提供するベンダーが理想 実例：Notepad++が悪用→サプライチェーン侵害→VulnCheckがDIBSプロセスで調整しCVEアサイン→CISA KEVへ掲載 DIBSプロセス：重複CVE発行を防ぐ協調メカニズム CNAが集まり、クリティカルな脆弱性に対して「誰がCVEを発行するか」を短期間で合意する非公式プロセス CVE重複発行リスクを減らしながら、対応速度を確保する リポジトリは公開されており参加可能 研究者コミュニティとの関係構築が重要 Project Discoveryなど、繰り返し脆弱性を報告する研究者コミュニティとの信頼関係を構築→深夜にLinkedIn経由でゼロデイ報告が届く Versa Connectの認証バイパス脆弱性：報告当夜にCVEを発行し、翌日にはShadow ServerおよびSibolが実運用環境での悪用を確認→CISA KEV掲載 脆弱性の悪用に関する初期情報は、研究者コミュニティやフォーラム、Discordなどに常駐する「perpetually online groups」によって最初にサーフェスすることが多く、そうしたシグナルをいかに早くキャッチできるかがカギになる 研究者クレジットの重要性 VulnCheckのInitial Accessチームの研究者（Kale）に加え、外部の脆弱性研究チームであるwatchTowr Labs、Code Whiteが同一の脆弱性をほぼ同時に発見する「researcher collision」が発生 全報告者に適切なクレジットを付与することが信頼を構築するうえで重要 ベンダーはアドバイザリとCVEレコード両方にクレジットを記載すべき AIによる影響（Q&Aより） 高スキル研究者が使えば高品質な脆弱性報告の大量提出が可能に スキルの低い報告者からの「スロップ（雑な報告）」も増加 脅威アクターはまだ古い枯れた脆弱性を多用しており、AIによる新規開発加速の実害はまだ計測困難だが、注視中 6. Taming the Scanner Storm: How VEX Brings Context to Vulnerability Data 発表： NVIDIA 前置き この発表はスキャナーから得られる脆弱性データをどう扱うかという話 今回は特にコンテナイメージにフォーカス 一部のイメージを対象に始めたプロジェクトで、その後すべてのコンテナイメージにVEXを適用できるようになった ※VEXとは： https://www.vuls.biz/blog/articles/20241105a#Vulnerability-Exploitability-eXchange-VEX （上記FutureVuls Blogを参考） 問題：スキャン結果が多すぎて開発者が動けない 34,000のコンテナイメージを毎日スキャン結果を更新→約2,690万件の脆弱性発見、24,536件のユニークなCVE そのうち66%はベンダーパッチが未提供（上流修正はあるがベンダーが未取り込み） スキャナーは「ベンダーが影響なしとしているか」「本当に悪用可能か」「偽陽性か」を判定しない VEX（Vulnerability Exploitability eXchange ※）オーバーレイシステムの設計 2段階パイプライン： Ubuntu（GitHub公開のVEX）とRed Hat（CSAF系VEX）を取り込み、正規化してCycloneDXとしてDBに格納 スキャン完了時にAPIがスキャンレポートにVEX情報を上書きする ルールエンジンでリスク許容度に応じた自動VEX適用ポリシーを設定 VEXアクションの優先順位（ルール） upgrade_suggested → 自動反映しない。修正版があるのでアップグレードを促す vendor_VEX-not_affected → Critical/High含む全深刻度で自動反映可 fix_available → vendor_VEX-not_affected より後順位で適用 vendor_VEX-affected → ベンダーが影響をMedium以下とする等、条件付きで自動反映し、開発者の追加調査の負担を減らす no_vex_or_upgrade_found → 原則は自動で判定せず。ただし最近公開された場合などはトリアージ中として扱う 実績データ 修正しなかったfindingsのうち94%でVEX情報に基づく判定が可能（CVE 2020以降） 中低深刻度1,700万件のうち84%にVEX情報が適用 Critical/Highは修正可能なものが多く積極的に修正指示 -2,600万件→VEX適用後、開発者が真に対応すべき件数を大幅削減 ベンダーが「影響なし」と言っていても顧客スキャナーでは検出されるため、SLAの設計が必要な課題として残る 学んだこと ベンダーごとのVEXフォーマット・更新頻度が異なり正規化が必須 スキャナー側がVEX情報を取り込んでいないケースがあり、業界全体での標準化・取り込みが課題 Alpine等まだ対応していないディストリビューションのVEX情報の取り込みが今後の課題 7. Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence 発表： Red Hat SBOMについて SBOM（Software Bill of Materials）は、ビルド工程で使われ、最終的なソフトウェアコンポーネントに含まれる全アーティファクトを機械可読で棚卸ししたもの 脆弱性管理において重要なのは、ソフトウェア資産全体の中からCVEを迅速に特定でき、修正の優先順位付けにも役立つため 規制（例：EU Cyber Resilience Act）やフレームワーク（例：NIST SSDF）でSBOM要求が増え、SPDX/CycloneDXやツール群で成熟してきた一方、複雑で現実的なコンテナビルドでは「SBOMが約束すること」と「実際に提供できること」にギャップがある 標準SBOM（Analyzed SBOM）の根本的な限界 コンテナイメージは複数のベース・ビルダーイメージからなるマルチステージビルドで構成 標準SBOMはフラットな「contains」リストのみを提供し、「なぜそのアーティファクトがそこにあるか」が不明 「誰が修正責任者か」がわからない状態でCVEが報告されるため、複数チームが無駄な調査・再ビルドに時間を浪費 誤った順序での再ビルドによりCVEが修正されない事態が起こり得る Contextual SBOMのコアコンセプト ビルドステップを精密に監視し、全アーティファクトをビルドアクション・生成イメージにマッピング 使用するSPDXのRelationshipType： CONTAINS ：コンテナイメージ内の標準的な包含関係 DESCENDANT_OF ：ベースイメージとの親子関係（例：アプリイメージ→UBI Python） BUILD_TOOL_OF ：マルチステージビルダーイメージとの関係 具体的な効果（ベースイメージの例） 脆弱なHTTPパッケージ検出時→Contextual SBOMから「UBI Pythonベースイメージに由来」と即座に判定 アプリケーション所有者ではなくベースイメージ所有者に通知 ベースイメージ修正後のCI/CDパイプラインの自動再ビルドを完全自動化 具体的な効果（ビルダーイメージの例） curl が脆弱→GoLang Builderイメージが起点と特定→アプリレイヤーにコピーされていない場合は最終アプリの再ビルド不要と判断可能 ソースコードの依存関係起因のCVE→ベースイメージ所有者・ビルダー所有者には通知不要 Contextual SBOM導入前後の比較 Before After アーティファクトの起源 不明 即座に特定可能 修正担当チーム 関係しそうなチームが巻き込まれ、担当特定に時間 担当チームを最初から特定でき、担当だけが動ける 再ビルド順序 試行錯誤・重複ビルド 最適な順序で自動実行 社内エスカレーション 全体アラートになりがち 「対応不要」と伝えられる 課題と呼びかけ アーティファクトの一意識別子（チェックサム・SPDXのPackage Verification Code）の一貫性が精度の前提 カスタムバイナリファイルなど一意識別子を持たないコンテンツでは起源特定が困難→「不確実状態」でフラグ付け SBOMツールエコシステム全体におけるContextual SBOM対応ツール開発への投資を呼びかけ Contextual SBOMの利用方法 Hermeto（※） 公開プロジェクトとして公開中、CI/CDパイプラインへの組み込み可能 ※Hermeto Project： https://github.com/hermetoproject 8. Lessons From NPM's Dark Side: Preventing the Next Shai-Hulud 発表： OpenSourceMalware.com 「偶発的脆弱性」vs「意図的マルウェア」の違い 偶発的：開発者のミスによるフロー、CVE対象、サードパーティライブラリが動いている場所で悪用、影響期間は長期間のケースがある 意図的：最初に感染するのは開発者PCやCI、影響期間は短命（axiosは3時間未満でレジストリから消えた）、シークレット窃取が主な目的 CVEの対処法（最新バージョンにアップグレード）が、マルウェアでは逆に感染経路になる なぜnpmが標的になるか postinstallなどのライフサイクルスクリプトがデフォルトで実行される（ダウンロード直後に感染） provenance（発行元証明）が必須ではなく、検証の習慣が根付いていない 長期有効トークン（Long-lived Access Token）が存在し、一度奪われると長期間悪用される さらにJavaScriptの推移的依存関係の多さも影響範囲の拡大を加速 2025年主要マルウェアキャンペーン（5件） eslint-config-prettier（7月）： 3800万DL/週。タイポスクワッティングドメインのフィッシングでトークン窃取→Windows開発環境でRCE is（7月）： 280万DL/週。「メンテナーの誤ったアクセス削除」を装うソーシャルエンジニアリング→クリプトウォレット・クラウドクレデンシャル窃取 NX（8月）： GitHubアクションの未発見脆弱性を悪用→AIツール（Claude・Gemini・Amazon Q）の設定を書き換えてマルウェアの共犯者化→370社・20,000ファイル以上流出（第2波で6,700リポジトリ追加公開） Quix（10月）： 26億DL/週。「2FA更新」を装うフィッシング→chalk・debugパッケージ含む28パッケージ侵害→$1,000相当の暗号通貨窃取 Shai-Hulud（9月・11月）： 187パッケージ掌握→TruffleHogを武器化してシークレットをスキャン→感染したパッケージを自動的に再公開するワーム機能→528リポジトリ公開化→第2波で492パッケージ追加侵害（ホームディレクトリ削除機能付き）→26,000リポジトリからクレデンシャル流出 2026年：TeamPCPによるTrivy・axios侵害 Trivy： 長期有効PATを悪用して悪意あるリリースを公開→LightLLMなど下流ツールも汚染 axios： 北朝鮮系脅威アクターによる高度なソーシャルエンジニアリング（偽のSlack連絡・偽のTeamsアップデート誘導によるマルウェア実行） Shai-Hulud第2波の被害を受けた組織の分析 侵害された30,000パッケージについて、どれだけの組織がシークレットをローテーションしたかを調査（Entro Security社による分析） 被害を受けた組織は1,000を超える 一定数の組織で、Shai-Hulud第2波から72時間後も有効なクレデンシャルを保持していた 被害組織は技術系企業だけでなく不動産・医療・保険など幅広い業種に及ぶ 防御策：npmメンテナー向け ハードウェアキー（YubiKeyなど）：ブラウザのオリジン不一致を拒否し、人的認証経路を保護 Trusted Publishing（GitHub OIDC）：CI/CDパイプラインのトークンを保護（採用率：過去ATO被害者で13%、Shai-Hulud被害者でさらに低い10.8%） セッションベーストークン（2025年12月npm導入）：長期トークンを廃止しExposure Window（露出期間）を縮小 防御策：利用者向け 開発者： バージョンピンニング、lockfile管理、自動アップデートの無効化、ライフサイクルスクリプトの無効化 プロダクトセキュリティ： 使用していない依存関係の削除、CIやAI IDE上でのマルウェアスキャン クラウドセキュリティ： シークレットローテーションの自動化・即時実行、異常なクレデンシャル使用の監視 インシデントレスポンス： 脅威インテリジェンスとのフィード統合、サプライチェーンのIRプレイブックの作成 Q & A パッケージ単位ではなく、リポジトリ単位でブロックするという考え方とは？ マルウェアを配布するには、パッケージ単体だけでなく、それを公開するためのインフラ（例：GitHubリポジトリ）が必要になる そのため、個々の悪性パッケージを追いかけるのではなく、以下の対応の方が、運用上効率的でスケールしやすいケースがある 悪性だと判明したGitHubリポジトリ自体をブロックする そのリポジトリから配布される成果物を包括的に遮断する クールダウン期間とは何か？なぜ有効なのか？ 新しいパッケージやバージョンを公開直後にすぐ使わず、一定時間待ってから利用する運用のこと 推奨される待機期間：2〜3日（理由：アカウント乗っ取りなどで公開された 悪性バージョンの多くは、その期間内に削除・検知されている） 攻撃を完全に防げるわけではないが、何もしない場合に比べてリスクを大きく下げられる実用的な防御策とされている クールダウン運用で問題になりがちな点は？ 重大な CVE 対応など、即時アップデートが必要な例外ケースが必ず発生する そのため、クールダウンを前提とする場合は、次が不可欠である 技術的にクールダウンを回避できる仕組み 誰が・どの条件で例外を承認するかという事前合意 実際の運用では、「24時間以内に全社が即時アップデート必須」というケースは稀 理論上の緊急性と、現場で実際に対応できる現実にはギャップがある まとめ VulnCon 2026では、脆弱性管理を取り巻くエコシステムが大きな転換点にあることが示されました。 NVDやCVEといった基盤は引き続き重要である一方、npmパッケージのマルウェアキャンペーンの事例が示すように、サプライチェーン攻撃のスピードと複雑さは増しており、単一の制度や指標だけでは実運用に耐えない場面が増えています。 また脆弱性管理において、VEXやContextual SBOMによる影響範囲の文脈化に加え、VulnCheckの発表が示したような「実際に悪用されている／されやすいか」という視点を組み合わせる重要性が強調されていました。 本記事で紹介したセッションは、これらの変化と課題を理解するうえで特に参考になる内容が多かったと感じました。 ちなみにバーチャル参加の場合、TLP:CLEARかつ2日目以降のセッションしか視聴できませんでした。 ネットワーキングパーティやワークショップへの参加、TLP:GREEN以上のセッションを視聴したい場合は、現地参加をご検討ください。 https://www.first.org/events/calendar/2027#start:2027-03-30 CVE/FIRST VulnCon 2027 & Annual CNA Summit - Save the Date Scottsdale, US March 30, 2027–April 2, 2027 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆： @fukuyama.kenta レビュー： @kobayashi.hinami （ Shodo で執筆されました ）