AWS Security Hubにサプライチェーンセキュリティが追加｜ChainguardとSocketで悪意ある依存関係を防ぐ

2026年8月4日、同じ日に起きた2つの出来事

2026年8月4日は、ソフトウェアサプライチェーンセキュリティの歴史において記憶すべき一日となりました。

npmパッケージ「keyv」が乗っ取られた日

その日の朝、広く使われているnpmパッケージ「keyv」が攻撃者に乗っ取られました。驚くべきことに、このマルウェアは単に感染するだけでなく、自己複製機能を持つワーム型であり、npm installを経由して400以上のnpmパッケージへと瞬く間に伝播しました。開発者が異変に気づいた時点では、すでに感染は広がっており、多くのCI/CDパイプラインが影響を受けていました。

同日、AWSが発表した「第10のセキュリティカテゴリ」

まるでこの事件に呼応するかのように、同じ8月4日にAWSは重要な発表を行いました。AWS Security Hub Extendedに、第10のセキュリティカテゴリとして**「サプライチェーンセキュリティ」が追加されたのです。パートナーとして参加したのは、予防型アプローチを取るChainguardと、検出型アプローチを取るSocket**の2社です。

偶然の一致とは思えないタイミングでした。AWSがこの領域に本格的に踏み込んだ背景には、依存関係を狙った攻撃の急増と高度化があります。

この記事で分かること

2026年にサプライチェーン攻撃が急増・高度化した理由とデータ
AWS Security Hub Extendedの新カテゴリの仕組みと導入メリット
Chainguard（予防型）とSocket（検出型）の違いと使い分け
自社への導入判断に使えるチェックリストと実践ステップ

なぜ今、依存関係セキュリティが最重要課題なのか

2026年に急増したnpmサプライチェーン攻撃

依存関係を狙った攻撃は、もはや「理論上のリスク」ではありません。2026年に入ってから、重大なインシデントが相次いで発生しています。

事件	時期	影響範囲
Axios妥協	2026年3月	週1億DL／17.4万依存パッケージ（北朝鮮関与）
AsyncAPI妥協	2026年7月14日	90分で5バージョンが悪意ある再配布
keyv妥協	2026年8月4日	400以上のパッケージにワームが伝播
ChainDropワーム	2026年8月	自己複製型マルウェアの初確認

Axiosの件では北朝鮮との関与が指摘され、国家レベルの脅威アクターがサプライチェーン攻撃に参入していることが明らかになりました。AsyncAPIの妥協は、わずか90分という猛烈なスピードで拡散しました。

累計123.3万個 ― ブロックされた悪意あるパッケージ数

2025年からの累計で、123.3万個を超える悪意あるパッケージがブロックされています。これは前年比75%増という数字であり、単なる量の増加にとどまらず、攻撃の質的な変化も顕著です。

かつての攻撃は「機会主義的な暗号通貨スキミング」が中心でした。しかし今や、国家支援型の持続的攻撃や、keyv事件で見られた自己複製型マルウェア（ワーム）へと高度化しています。ChainDropワームは業界で「攻撃の工業化」と呼ばれており、一度侵入に成功すると人間の介入なしに感染を広げる点が従来と根本的に異なります。

従来のSCAツールが無力だった理由

多くの組織がすでにSCA（Software Composition Analysis）ツールを導入しています。しかし、このカテゴリのツールが中心としているのは既知CVEのデータベースマッチングです。

問題は、悪意あるパッケージの多くがCVEとして登録されていないゼロデイであるという点です。「脆弱性を探す」という行為と「マルウェアを探す」という行為は、根本的に異なるアプローチを要求します。脆弱性は合法的なコードの欠陥であり、マルウェアは意図的に埋め込まれた悪意です。既存のSCAツールは前者には有効ですが、後者に対しては原理的に限界があります。

AWS Security Hub Extendedの新カテゴリを理解する

そもそもAWS Security Hub Extendedとは

AWS Security Hubは、AWS環境のセキュリティアラートを一元管理するサービスです。その拡張版であるAWS Security Hub Extendedは、AWSネイティブの検出機能に加え、サードパーティのパートナーソリューションを統合管理するレイヤーとして機能します。

従来のSecurity Hubが「AWSリソースの設定不備や脅威検出」に特化していたのに対し、Extendedはパートナーエコシステムを含む広範なセキュリティ領域をカバーします。

追加された第10カテゴリ「サプライチェーンセキュリティ」

今回追加されたカテゴリは、既存の9カテゴリ（エンドポイント、ネットワーク、IDなど）に次ぐ第10の柱として位置づけられています。重要なのは、このカテゴリがCI/CDパイプラインの内側、つまりコードが書かれてからデプロイされるまでのプロセス全体をカバー範囲に含める点です。

これにより、インフラ層だけでなく、アプリケーション開発プロセス自体のセキュリティ可視性が大幅に向上します。

23のパートナーソリューションを単一請求で

AWS Security Hub Extendedでは、ChainguardとSocketを含む23のパートナーソリューションを、AWSの単一請求で利用できます。長期契約が不要で従量課金制であるため、まず検出モードで試してから本格導入を検討するといったPoC（概念実証）のハードルが大幅に下がります。

通常、セキュリティツールの導入には調達プロセスや複数ベンダーとの契約が伴います。この統合請求モデルは、特に調達リソースが限られる中規模組織にとって現実的なメリットです。

OCSF形式による検出結果の自動集約

📘 用語解説｜ OCSF（Open Cybersecurity Schema Framework） 複数のセキュリティツールが生成するイベントデータを、共通のフォーマットに統一するためのオープン標準。AWSやSplunk、Cloudflareなど60社以上が参加するコンソーシアムが策定。異なるツールのアラートを同じ構造で扱えるため、分析・自動化・SIEM連携が容易になる。

複数のセキュリティツールを使う組織が直面する最大の課題のひとつが「アラートの断片化」です。ツールごとにフォーマットが異なると、SOCチームは各ツールのコンソールを行き来しながら手動で相関分析を行う必要があります。

OCSF形式での自動集約により、ChainguardとSocketの検出結果がAWS Security Hub上で統一されたビューで確認できます。これは単なる「見た目の統合」ではなく、自動化されたインシデントレスポンスへの基盤となります。なお、本機能は全AWSコマーシャルリージョンで利用可能です。

Chainguard ― 「そもそも汚染物を入れない」予防型アプローチ

98%のマルウェアはプリビルドパッケージとして届く

Chainguardが着目したのは、マルウェアの配布構造です。攻撃者が悪意あるコードを埋め込む際、そのほとんどはソースコードを改ざんするのではなく、ビルド済みのバイナリやパッケージに仕込みます。Chainguardによれば、98%のマルウェアはプリビルドパッケージとして配布されています。

つまり、開発者がGitHub上のソースコードを確認しても、実際にダウンロードされるnpmレジストリ上のパッケージとは中身が異なる可能性があるのです。この「ソースコードとレジストリ配布物の乖離」こそが、攻撃者が突く構造的な盲点です。

ソースからの再ビルドで99.7%のマルウェアを設計段階で排除

Chainguardの回答は明快です。**「信頼できるソースから自分たちでビルドし直す」**という方法です。

Chainguard Librariesは、オープンソースパッケージをソースコードから検証済みの環境で再ビルドし、マルウェアフリーな状態で提供します。同社の発表によれば、この手法により設計段階で99.7%のマルウェアを排除できるとされています（※ベンダー公表値）。

SLSA Level 3準拠のビルド環境「Chainguard Factory」

📘 用語解説｜ SLSA（Supply-chain Levels for Software Artifacts） Google主導で策定されたサプライチェーンセキュリティのフレームワーク。Level 1〜4の段階でビルドプロセスの改ざん耐性を評価する。Level 3は「ビルド環境が完全に独立・検証可能であり、ビルドプロセスへの人間の直接介入が不可能」な状態を意味する。

Chainguardのビルド環境「Chainguard Factory」はSLSA Level 3に準拠しています。これは、ビルドプロセス自体が改ざんされていないことを暗号学的に証明できることを意味します。

署名付きプロベナンスとSBOMの同梱

📘 用語解説｜ SBOM（Software Bill of Materials） ソフトウェアを構成するコンポーネントの一覧表。食品の原材料表示に相当し、どのライブラリのどのバージョンが使われているかを記録する。米国の大統領令（EO 14028）や欧州のCRA（サイバーレジリエンス法）など、規制対応でも要求が増えている。

Chainguard Librariesには、署名付きプロベナンス（ビルドの来歴証明）とSBOMが同梱されています。これにより、監査やコンプライアンス対応での実務的なメリットが生まれます。顧客や規制当局からSBOMの提出を求められた際にも、即座に対応できます。

対応エコシステム

現在、Chainguard LibrariesはJavaScript（73,000以上のパッケージ）、Python、Javaに対応しています。これらの言語が主要な組織では特に効果が高く、逆にGo単独の環境など対応範囲外の言語のみを使う場合は適用可否を個別に確認する必要があります。

Socket ― 「怪しい振る舞い」を捕まえる検出型アプローチ

Socket Firewallによるインストール時リアルタイムブロック

Socketのアプローチは、Chainguardとは異なるレイヤーに防御ポイントを設けます。Socket Firewallは、npm installの実行そのものを防御ポイントとし、悪意あるパッケージをインストール時にリアルタイムでブロックします。

開発者のワークフローを極力阻害しない設計となっており、既存の開発プロセスに追加する形で導入できます。

行動分析（Behavioral Analysis）という検出手法

Socketの核心は、**行動分析（Behavioral Analysis）**にあります。既知の脆弱性データベースへのマッチングではなく、パッケージが「何をしようとしているか」を動的に分析します。

たとえば、インストール時にネットワーク接続を試みる、環境変数を読み出そうとする、シェルコマンドを実行しようとする、といった不審な振る舞いを検出します。この手法により、CVEとして登録されていない未知のマルウェアや、シグネチャベースのツールが見逃す「新種の攻撃」を捕捉できます。

幅広いエコシステム対応

Socketはnpm、PyPI、Maven、Go、NuGet、RubyGemsと主要なパッケージエコシステムを幅広くカバーしています。複数言語を使うポリグロットな組織ほど、一つのツールで横断的に対応できるメリットが大きくなります。

予防 vs 検出 ― 2つのアプローチはどう使い分けるか

比較表で整理する

観点	Chainguard	Socket
基本思想	予防（汚染物を入れない）	検出（怪しい動作をブロック）
防御ポイント	パッケージ供給源	インストール実行時
対応言語	JS / Python / Java	npm / PyPI / Maven / Go / NuGet / RubyGems
強み	設計段階での根本解決	未知の攻撃への即応性
導入影響	依存パッケージ取得先の変更	既存ワークフローに追加

「どちらか」ではなく「両方」が理にかなう理由

実際の開発現場では、どちらか一方を選ぶよりも両方を組み合わせることが多層防御（Defense in Depth）の観点から理にかなっています。

Chainguardが再ビルドの対象としているのは、現時点でJavaScript・Python・Javaのパッケージです。それ以外のエコシステムや、再ビルド対象外のパッケージについては、Socketの行動分析が補完的に機能します。つまり、2つのツールは競合するのではなく、カバレッジを補い合う関係にあります。

Security Hubで一元管理する意味

ここでAWS Security Hub Extendedが真価を発揮します。ChainguardとSocketの検出結果は、どちらもOCSF形式でSecurity Hubに集約されます。SOCチームは複数のダッシュボードを行き来することなく、一つの画面でサプライチェーンリスクの全体像を把握できます。

アラート疲れ（Alert Fatigue）は現代のセキュリティ運用における深刻な問題です。統合管理することで、アラートの優先付けと対応フローの自動化が現実的な選択肢となります。

実践ガイド ― 自社に導入すべきか判断する

優先度が高い組織の特徴（チェックリスト）

以下に多く当てはまる組織ほど、導入を優先的に検討すべきです。

npm / PyPI依存が数百パッケージ以上ある
SaaS / 金融 / 医療など規制業界に属する
CI/CDが自動化され、依存関係の更新が頻繁に行われている
顧客や取引先からSBOMの提出を求められている
すでにAWSを主要インフラとして利用している
既存のSCAツールのみで依存関係リスクに対応している

導入ステップの目安

段階的に理解を深めながら進めることをベストプラクティスとして推奨します。

現状の依存関係を棚卸しする（SBOMを生成し、依存の深さを可視化）
Security Hub Extendedでパートナーを有効化（まず検出モードで開始）
ノイズ量を計測する（誤検知の頻度と傾向を把握）
クリティカルなリポジトリからブロックを適用（段階的に展開）
アラートのエスカレーションフローを定義（誰がどう対応するかを決める）

導入前に確認したい落とし穴

技術的に正確な表現を心がけると、以下の点は事前に把握しておく必要があります。

誤検知（False Positive）のリスク: 行動分析ベースの検出は、合法的なパッケージを誤ってブロックする可能性があります。開発速度への影響を最小化するため、まず検出のみのモードで運用し、誤検知パターンを把握してからブロックを有効化することを推奨します。

コストの試算: 従量課金制は小規模スタートに向いていますが、スケールしたときの費用は事前にシミュレーションしておきましょう。

既存ツールとの役割整理: すでにSnykやDependabotなどのSCAツールを導入している場合、それらとの役割の重複・補完関係を明確にしておくことで、予算と運用コストを最適化できます。

今すぐできる、コストゼロの対策

ツール導入の前に、まず以下の運用ルールを確認・徹底しましょう。

npm ciとlockfileの徹底: npm installではなくnpm ciを使うことで、lockfileと一致しないパッケージのインストールを防止できます
--ignore-scriptsの活用: npm install --ignore-scriptsにより、パッケージのインストール時に自動実行されるスクリプトを無効化できます
依存更新の自動マージを止める: DependabotやRenovateの自動マージは便利ですが、PRのレビューを必須化することで意図しない依存変更を防げます

まとめ ― 依存関係は「信頼するもの」から「検証するもの」へ

この記事の要点3つ

① サプライチェーン攻撃は自己複製型へと高度化した 2026年の攻撃は、国家支援型かつワーム型へと進化しています。npm install一回で数百パッケージに感染が広がる世界では、「有名パッケージだから安全」という前提はもはや成立しません。

② AWSが第10カテゴリを追加し、統合管理の受け皿ができた AWS Security Hub ExtendedのサプライチェーンセキュリティカテゴリはCI/CDパイプラインの内側をカバーし、23のパートナーソリューションをOCSF形式で集約します。既存のAWSユーザーにとって、導入障壁が大幅に下がりました。

③ Chainguard（予防）とSocket（検出）は補完関係にある 「汚染されたパッケージを供給源で排除する」予防と、「怪しい振る舞いをインストール時にブロックする」検出を組み合わせることで、既存のSCAツールでは対応できなかったゼロデイの悪意あるパッケージへの防御が現実のものとなります。

依存関係は、もはや「信頼するもの」ではなく「継続的に検証するもの」です。今回のAWSの発表は、その検証を開発ワークフローに自然に組み込むための、重要な一歩といえるでしょう。

次に読むべき情報源

AWS What's New: Security Hub Extended adds Supply Chain Security
Chainguard公式ブログ（Chainguard Libraries・SLSA・プロベナンスの詳細）
Socket公式ブログ（行動分析・Socket Firewallの詳細）
SLSA公式サイト: slsa.dev（フレームワーク全体像）
CISA SBOM関連ガイダンス（コンプライアンス対応の参考）