公開：2025年7月24日
12分で読めます
ソフトウェアサプライチェーンのセキュリティガイド：組織が直面する課題とは
この新シリーズの第1部では、すべての開発チームが理解すべき、基本的な課題、実践的な解決策、そしてAIを含む新たなトレンドを探ります。
大抵の開発チームは、サプライチェーンセキュリティについて尋ねられると、脆弱性スキャンや依存関係の管理を挙げるでしょう。確かにそれらはサプライチェーンセキュリティの構成要素ではありますが、実際の課題のごく一部であり、その視点は非常に限定的で、危険です。
サプライチェーンセキュリティとは、単に依存関係をスキャンすることではありません。 コードの作成から本番環境へのデプロイまで、以下を含む一連のプロセス全体を対象としています。
- ソースセキュリティ：コードリポジトリの保護、コントリビューターのアクセス管理、コードの整合性の確保
- ビルドセキュリティ：ビルド環境の保護、コンパイルやパッケージ化時の改ざん防止
- アーティファクトセキュリティ：コンテナやパッケージ、デプロイ用アーティファクトの整合性の確保
- デプロイセキュリティ：配信手段および実行環境の保護
- ツールセキュリティ：開発ツールやプラットフォーム自体の強化
サプライチェーンセキュリティにおける「チェーン」とは、この一連の相互に連携したステップを指します。チェーンのどこかに脆弱性があると、ソフトウェアデリバリーのプロセス全体が危険にさらされてしまいます。
2020年に発生したSolarWinds攻撃は、その典型的な例です。これは史上最大級のサプライチェーン攻撃の一つであり、国家の支援を受けた攻撃者がSolarWindsのネットワーク管理ソフト「Orion」のビルドパイプラインを侵害しました。攻撃者は脆弱な依存関係を悪用したり、完成したアプリケーションをハッキングしたのではなく、コンパイルプロセスそのものに悪意あるコードを注入したのです。
その結果は壊滅的でした。通常のソフトウェアアップデートを通じて、米国政府機関を含む18,000以上の組織が、気づかないうちにバックドア付きのソフトウェアをインストールしてしまいました。ソースコードには問題がなく、完成したアプリケーションも正規のものに見えましたが、ビルドプロセスが攻撃手段として利用されていたのです。この攻撃は数か月にわたって検出されず、サプライチェーンの脆弱性が従来のセキュリティ対策をいかに回避できるかを示す事例となりました。
組織を脆弱にするよくある誤解
サプライチェーンの脅威に対する認識は高まりつつありますが、多くの組織はいまだに危険にさらされています。というのも、「ソフトウェアサプライチェーンセキュリティとは何か」という根本的な理解に誤りがあるからです。こうした誤解が、重大な見落としを生んでしまいます。
- ソフトウェアサプライチェーンセキュリティは依存関係スキャンだけだと考えている
- オープンソースコンポーネントにばかり注目し、プロプライエタリコードのリスクを無視している
- コード署名だけで十分に保護できると思っている
- 安全なコーディング慣行さえ守っていれば、サプライチェーンのリスクはなくなると考えている
- サプライチェーンセキュリティを、セキュリティチームだけの問題だと捉え、開発ワークフローの課題として見ていない
AIが新たな脅威に
多くの組織が従来型のソフトウェアサプライチェーンセキュリティの課題に取り組んでいる中、人工知能（AI）はまったく新しい攻撃ベクトルを生み出し、既存のリスクをこれまでにない形で拡大させています。
AIによる攻撃：より巧妙に、より大規模に
攻撃者はAIを使って脆弱性の発見を自動化し、デベロッパーを狙った巧妙なソーシャルエンジニアリング攻撃を作成し、公開されているコードベースを体系的に分析して弱点を探しています。かつては手作業でしか行えなかったことが、いまや正確かつ大規模に実行できるようになっています。
AI開発のサプライチェーンがもたらす新たなリスク
AIは開発ライフサイクル全体を再構築していますが、それと同時に深刻なセキュリティの死角も生み出しています。
- モデルのサプライチェーン攻撃：Hugging FaceやGitHubなどから提供される事前学習済みモデルには、バックドアや汚染されたトレーニングデータが含まれている恐れがあります。
- 安全でないAI生成コード：AIコードアシスタントを使うデベロッパーが、気づかないうちに脆弱なパターンや危険な依存関係を導入することがあります。
- 危険にさらされたAIツールチェーン：AIモデルの学習、デプロイ、管理に使われるインフラが、新たなアタックサーフェス（攻撃対象領域）となります。
- 自動化された偵察：AIにより、攻撃者はエコシステム全体をスキャンして、高リスクなサプライチェーンの標的を特定できます。
- シャドーAIと非公認ツール：デベロッパーが、安全性が確認されていない外部AIツールを組み込んでしまうことがあります。
その結果どうなるか？AIは単に新しい脆弱性をもたらすだけでなく、既存のリスクの規模と影響を増幅します。もはや、段階的な改善では追いつけません。脅威の状況は、現在のセキュリティ対策が対応できるスピードを上回る勢いで進化しています。
多くの組織がいまだに苦戦している理由
サプライチェーンセキュリティの重要性を理解している組織でさえ、効果的に対処できていないことがよくあります。統計は、「認識しているのに行動が伴わない」という深刻な傾向を明らかにしています。
2021年にコロニアル・パイプライン社が業務復旧のためにハッカーに440万ドルを支払った事件や、18,000もの組織が被害を受けたSolarWinds攻撃は、サプライチェーンの脆弱性が、重要インフラを停止させ、かつてない規模で機密データを危険にさらす可能性があることを世に知らしめました。
それにもかかわらず、多くの組織はいまだに従来どおりの運用を続けています。本質的な問いは、「組織がサプライチェーンセキュリティを重要だと考えているか」ではなく、「なぜそう考えていても、実効的な対策につながらないのか」という点です。
その答えは、効果的な行動を妨げている4つの重要な障壁にあります。
1. 誤った「コスト優先」思考
組織はしばしば、「最も効果的な方法は何か？」ではなく、「コストがかからないのはどれか？」という観点で考えてしまいます。こうしたコスト第一の考え方は、後に高くつく問題を生み出すことになります。
2. スキル不足という現実
BSIMM（Building Security In Maturity Model）の調査によると、組織にはデベロッパー100人あたり平均でセキュリティ専門家がわずか4人しかおらず、さらにISC2の調査では、90%の組織が深刻なサイバーセキュリティ人材の不足を報告しています。このような状況では、従来のアプローチをスケールさせることは数学的に不可能です。
3. 組織内のインセンティブの不一致
デベロッパーのOKR（Objective and Key Results）は機能の開発速度に重点が置かれる一方で、セキュリティチームはまったく異なる成果を指標にしています。経営陣が市場投入のスピードをセキュリティ対策状況よりも重視するような状況では、部門間の摩擦は避けられません。
4. 複雑すぎるツール環境
一般的な企業では平均して45種類ものサイバーセキュリティツールを使っており、そのうちの40%は誤検知です。また、インシデント対応には平均して19種類ものツールをまたいで調整を行う必要があります。
こうした障壁によって悪循環が生まれます。組織は脅威を認識し、セキュリティソリューションに投資はするものの、期待される効果が得られるような実装ができていないのです。
サプライチェーンの脆弱性がもたらす本当の代償
サプライチェーン攻撃によって生じるリスクとコストは、初期の対処だけでは収まりません。こうした見えにくい追加的な負担を理解することで、予防が「望ましい」どころか、「ビジネスを継続するために不可欠」だということがわかります。
時間が最大の敵になる
評判へのダメージは拡大する一方
攻撃者にサプライチェーンを突破された場合、奪われるのはデータだけではありません。顧客との信頼関係という土台そのものが揺らいでしまいます。実際、侵害後には顧客の解約率が平均で33%上昇し、パートナーとの関係も再認証プロセスなどで多大なコストが発生します。さらに、「より安全だと見なされる」競合に見込み顧客が流れてしまい、競争力の低下にもつながります。
規制の現実が重くのしかかる
規制の状況は根本的に変化しています。GDPR（EU一般データ保護規則）による罰金は、重大なデータ侵害の場合、平均して5,000万ドルを超えています。EUの新しいサイバーレジリエンス法では、サプライチェーンの透明性が義務づけられています。アメリカの連邦契約業者は、すべてのソフトウェア購入においてソフトウェア部品表（SBOM）を提供しなければならず、この要件は民間企業の調達にも急速に広がりつつあります。
業務への混乱がさらに広がる
直接的なコストだけでなく、サプライチェーン攻撃は、攻撃対応中のプラットフォームのダウンタイム、テクノロジースタック全体にわたる緊急セキュリティ監査、顧客からの訴訟や規制当局の調査による法的コストなど、業務に深刻な混乱をもたらします。
現在のアプローチの問題点
多くの組織は、「セキュリティ対策をしていること」と「実際にセキュリティ効果があること」を混同しています。スキャナーを導入し、長大なレポートを作成して、各チームに手作業で対応させています。こうした取り組みはしばしば逆効果で、問題を解決するどころか、かえって新たな問題を生んでしまいます。
大量のスキャンvs.実効性のある保護
企業は毎月1万件以上のセキュリティアラートを生成しており、中には1日15万件ものイベントを記録するケースもあります。しかし、これらの63%は誤検出や優先度の低いノイズにすぎません。結果として、セキュリティチームは処理しきれず、推進役ではなくボトルネックになってしまいます。
コラボレーションの崩壊
最も安全な組織というのは、ツールをたくさん使っている組織ではなく、DevSecOps間の連携が強い組織です。しかし、現在のほとんどの体制では、この連携が難しくなっています。ワークフローが互換性のないツールで分断されているため、デベロッパーは自分の環境でセキュリティ結果を確認できず、リスクやビジネスへの影響もチーム間で共有できていません。
今後に向けて
こうした課題を理解することが、効果的なソフトウェアサプライチェーンセキュリティを構築するための第一歩です。成功している組織は、単にセキュリティツールを追加するのではなく、セキュリティを開発ワークフローにどのように統合するかを根本から見直しています。また、ソフトウエアデリバリーのプロセス全体を振り返り、プロセスの簡素化、ツールの削減、コラボレーションの改善にも取り組んでいます。
GitLabでは、統合型DevSecOpsプラットフォームによって、セキュリティが開発ワークフローに直接組み込まれることで、こうした課題に対応できることを目の当たりにしてきました。このシリーズの次回の記事では、先進的な組織がどのようにして「デベロッパーにとって使いやすいソリューション」や「AIによる自動化」、そして「セキュリティをソフトウェア開発の自然な一部にできるプラットフォーム」を活用し、サプライチェーンセキュリティへの取り組みを根本から変えているのかをご紹介します。
GitLabのソフトウェアサプライチェーンのセキュリティ機能について詳しくは、こちらをご覧ください。