【ITニュース解説】Your SOC 2 Compliance Won't Stop Supply Chain Attacks (And I Have the Data to Prove It)

近年、多くの企業がセキュリティ対策の基準としてSOC 2コンプライアンス（SOC 2準拠）の取得を重視しているが、これがサプライチェーン攻撃に対する万全の防御策ではないという現状が指摘されている。実際には、SOC 2準拠を果たしている企業であっても、サプライチェーンを介した攻撃により甚大な被害を受けるケースが頻発しており、その実態はデータによって裏付けられている。

セキュリティに関する調査レポートは、この問題の深刻さを示している。Verizonの2025年データ侵害レポートによると、すべてのデータ侵害の30%がサードパーティ、つまり外部の協力企業を介して発生しており、これはわずか1年で倍増した数値である。IBMの2025年データ侵害コストレポートでは、データ侵害1件あたりの平均コストが世界で444万ドル、米国では1022万ドルに達し、サプライチェーンを原因とする侵害の場合、その検出から修復までにかかる日数は平均267日と非常に長いことが報告されている。さらに、BlackBerry Researchの調査では、昨年に75%の組織がサプライチェーン攻撃の被害を受けていることが判明しており、多くの企業がこの脅威に直面していることがわかる。

具体的なサプライチェーン攻撃の事例を見ると、この問題の深刻さが一層明確になる。2020年に発生したSolarWinds事件では、ロシアのハッカーがSolarWinds社のソフトウェア開発環境に侵入し、正規のソフトウェアアップデートに悪意のあるコードを組み込んだ。その結果、SolarWindsの顧客である約18,000の企業がマルウェアに感染し、SOC 2に準拠していた多くの企業も被害を受けた。この事件は、自社がセキュリティ基準を満たしていても、ベンダーのセキュリティが脆弱であれば攻撃を受けるという教訓を示している。

2023年の3CX事件では、さらに複雑な攻撃経路が明らかになった。攻撃者はまずTrading Technologies社のソフトウェアを侵害し、そのソフトウェアを3CX社の従業員がダウンロードしたことを足がかりに、3CX社の内部ネットワークへと侵入した。その後、3CX社のビルドサーバーを乗っ取り、正規の3CX製品のアップデートにマルウェアを仕込み、最終的に3CXの顧客全体に配布した。これは、一つのベンダーのセキュリティ侵害が連鎖的に複数の組織に影響を及ぼす典型的な例である。

そして、2024年に発覚したXZ Utils事件は、オープンソースソフトウェアに対する新たな脅威の形を示した。攻撃者は2年以上にわたりオープンソースコミュニティ内で信頼を築き、最終的に人気の圧縮ライブラリであるXZ Utilsのメンテナーの地位を獲得した。その後、ライブラリにバックドアを仕込み、数百万台のLinuxサーバーに不正アクセスできる状態にしようと試みたが、偶然により発見された。この事例は、広く利用されているオープンソースコンポーネメントへの依存が、潜在的なセキュリティリスクとなりうることを示している。

これらの事例とデータから、SOC 2監査には3つの主要な盲点があることが浮き彫りになる。

第一に「ベンダーセキュリティシアター」である。SOC 2監査では、企業がベンダーのリスクを評価しているかどうかが問われるが、多くの場合、企業はベンダーから提出された年次のSOC 2レポートを収集するだけで済ませてしまう。しかし、これらのレポートは特定の時点でのセキュリティ状況を示す静的な情報に過ぎず、ベンダーのセキュリティがリアルタイムで脅威にさらされている可能性を見落とす。ReversingLabsの調査によれば、オープンソースリポジトリで発見された悪意のあるパッケージは2019年以降70万件を超え、2020年から2023年にかけて1300%も増加している。この状況下で、過去のレポートだけを信頼することは危険である。

第二に「SBOM（Software Bill of Materials）ギャップ」である。多くの企業は、自社のプロダクションアプリケーションにどのようなサードパーティ製コンポーネントが実際に使用されているかを正確に把握していない。Log4jのような深刻な脆弱性が発見された際、SBOMを保有していた企業は自社の影響範囲を数分で特定できたのに対し、SBOMを持たない企業は影響調査に数週間を要した。ソフトウェアの構成要素を把握していなければ、新たな脆弱性が発生した際に迅速な対応が不可能となる。

第三に「ビルドパイプラインの前提」である。開発環境や継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインは厳重に保護されていると考えがちだが、ビルド時にnpm、PyPI、Maven Centralなどの外部リポジトリから取り込むパッケージのセキュリティについては十分な注意が払われていないことが多い。SolarWindsと3CXの事例が示すように、これらのビルドプロセスが攻撃経路となる可能性があり、開発者の手元のPCだけでなく、ビルド環境全体を防御する視点が必要である。

これらの盲点に対処し、サプライチェーン攻撃から企業を守るためには、SOC 2監査に加えて、より実践的なセキュリティ対策を導入することが不可欠である。

まず、「ソフトウェア部品表（SBOM）の導入」が重要となる。これは、自社のソフトウェアがどのような商用・オープンソースコンポーネントで構成されているかをリスト化したものであり、SPDXやCycloneDXといった標準形式がある。SBOMを作成することで、未知の脆弱性が発見された際に、自社のシステムが影響を受けるかどうかを迅速に判断し、対応することが可能となる。

次に、「依存関係スキャン」を継続的に実施することである。Snyk、OWASP Dependency-Check、GitHubのセキュリティ機能といったツールを活用し、アプリケーションが依存するライブラリやフレームワークに既知の脆弱性がないかを自動的にチェックする。これをCI/CDパイプラインに組み込むことで、問題が本番環境にデプロイされる前に検出・修正できる。

さらに、「SOC 2を超えるベンダー監視」が必要である。年次のSOC 2レポートの収集に留まらず、取引のあるベンダーのセキュリティ体制を継続的に監視する仕組みを構築すべきである。ベンダーのセキュリティイベントや脆弱性情報をリアルタイムで把握し、自社へのリスクを評価する体制が求められる。

最後に、自社のサプライチェーンセキュリティ状況を自己評価することが重要である。主要なアプリケーションについてSBOMを生成できるか、依存関係の脆弱性スキャンを自動的に行っているか、重要なベンダーが侵害された場合に24時間以内にそれを把握できるか、ビルド時にダウンロードするパッケージの整合性を検証できるか、といった点をチェックする。これらの質問に対し一つでも「いいえ」と答えるならば、SOC 2コンプライアンスだけでは実際のセキュリティリスクを十分にカバーできていない可能性があると認識すべきである。真のセキュリティは、形式的なコンプライアンスを超えた、継続的かつ実践的な対策によってのみ実現される。