2026年に押さえるべきソフトウェアサプライチェーンセキュリティのベストプラクティス7選

なぜソフトウェアサプライチェーンセキュリティが重要なのか

セキュリティの強度は最も弱い部分（ウィーケストリンク）によって決まり、その弱点となりやすいのがソフトウェアサプライチェーンです。近年、世間の注目を集めた情報漏えいの多くは、マルウェアやずさんなアイデンティティ・アクセス管理（IAM）が原因で攻撃者グループに侵害されたサードパーティにまでさかのぼることができます。

たとえば2020年には、攻撃者がソフトウェアベンダーであるSolarWindsのIT監視システム「SolarWinds Orion」へのアクセスを獲得しました。これにより、同社の3万社を超える顧客が危険にさらされる可能性が生じました。もう一つの有名な攻撃として、NPMパッケージを侵害した「Shai-Hulud」ワームによるものが挙げられます。

組織がサードパーティのツール、アクセス権、ソフトウェアコンポーネントなどへの依存を強めるほど、攻撃者にとっての潜在的な攻撃経路が生まれます。自社のデータやアプリケーションにアクセスできるサードパーティのセキュリティ対策が不十分、あるいは皆無であれば、自社のセキュリティ対策や統制も弱体化してしまいます。

2025年版のVerizon Data Breach Investigations Report（データ漏えい/侵害調査報告書）によると、情報漏えいの30%にサードパーティの関与が関係しており、これは前年の2倍に当たります。

したがって、サプライチェーンセキュリティの導入が重要になります。そのためには、サードパーティのツールや連携がどこに存在するかを把握し、セキュリティ上の脅威がないか監視する必要があります。

クラウドセキュリティ態勢を改善し、セキュリティリスクを低減するために、以下の7つのソフトウェアサプライチェーンセキュリティのベストプラクティスをご活用ください。

1. リスク耐性を前提としたセキュリティ戦略を設計する

攻撃者は必ず侵入してきます。問題は「侵入されるかどうか」ではなく「いつ侵入されるか」です。そのため、完全な侵入防止を目指すのではなく、攻撃者がファイアウォールなどの境界防御を突破した際にできることを制限する、多層防御（defense-in-depth）のセキュリティ戦略を導入しましょう。

多層防御戦略では、インシデント発生時にその影響を限定・緩和できるだけの十分なセキュリティの冗長性を確保します。最も保護を必要とするものは何か、そして攻撃者がそのビジネス上重要なデータに到達するリスクはどの程度かを見極めます。

リスクプロファイルを把握したら、必要な箇所に追加のセキュリティ技術・統制・ポリシーを導入し始めます。たとえばネットワークのマイクロセグメンテーションを実装すれば、攻撃者が初期の防御を突破しても、すべてに自動的にアクセスできるわけではない状態をつくれます。

検討に値する優れた方法論の一つがゼロトラストです。これは「決して信頼せず、常に検証する（never trust, always verify）」という方針を軸にセキュリティを強化する考え方です。

次の点を検討してください：

• データの暗号化：保存時・使用時・転送時のいずれにおいても、データは暗号化されていますか？
• IAM統制：ロールベースのアクセス制御を導入し、最小権限の原則に基づいてアカウントの権限を管理していますか？
• ファイル整合性監視：不正なアカウントが機密ファイルやシステムに変更を加えた場合、どのようにそれを検知しますか？
‍

2. セキュアコーディングを実践する

自社でアプリケーションを開発している場合は、開発者がセキュアソフトウェア開発ライフサイクル（SSDLC）に従うようにしましょう。SSDLCは、セキュリティをアプリケーション開発の全フェーズに組み込む「シフトレフト」の取り組みの一環です。

SSDLCは継続的なプロセスとして位置づけられており、組織がセキュリティのベストプラクティスを順守し、アプリケーション開発を安全に保てるようにするものです。

セキュアなCI/CDパイプラインを実現する方法には、次のようなものがあります：

• 自社のアプリケーションとそのユーザー層に固有のセキュリティリスクと、その緩和方法を特定する。
• セキュアな認証・認可を実装する。
• 一般的なセキュリティ脆弱性や弱点に対してビルドをテストする。
• ビルドプロセスを監査し、最新のセキュリティのベストプラクティスが反映されていることを確認する。
• サードパーティのコンポーネントや依存関係を使用する前に検証する。
• OWASP Security Knowledge FrameworkやOpenSSF Supply Chain Levels for Software Artifacts（SLSA）などの、コード解析・脆弱性スキャン・セキュリティフレームワークを導入する。

3. 厳格なセキュリティ衛生（セキュリティハイジーン）でサードパーティリスクを緩和する

リスク評価の一環として、サードパーティのソフトウェアコンポーネント・依存関係・ライブラリの利用によって生じるセキュリティリスクをどう管理するかも検討すべきです。そのためには、提供元（パブリッシャー）のセキュリティ対策や、オープンソースライブラリに脆弱性が見つかった場合に将来もサポートが受けられるかどうかを、時間をかけて把握する必要があります。

当然ながら、可能な場合にはサードパーティのコンポーネントや依存関係を使用する範囲を絞ることで、リスクを最小化できます。自社で開発できるものは内製し、それ以外のコンポーネントは、サードパーティのセキュリティ衛生対策を十分に評価したうえでのみ利用しましょう。

これには、提供元を調査し、どの程度の頻度でソフトウェアを更新・パッチ適用しているかを把握することが含まれます。提供元の現在のセキュリティ対策がどのようなもので、それが自社の業界やリスク許容度に照らして十分に厳格かどうかを確認します。

CISA（米国サイバーセキュリティ・インフラセキュリティ庁）は、脆弱性緩和に必要なセキュリティと統制の水準を明記した契約を提供元と取り交わすことを推奨しています。サードパーティに対しては、セキュリティ対策に関する自己認証（self-attestation）の提出、ソフトウェアのソフトウェア部品表（SBOM）の共有、そしてセキュリティ上の欠陥が生じた際の顧客への連絡手順の説明を求めましょう。

ソフトウェアを受領した後は、自社のセキュリティチームがそれを精査し、安全性を検証すべきです。たとえばソフトウェア構成分析（SCA）ツールを使って依存関係をスキャンしてから、ビルドに追加するようにします。

提供元と契約してその依存関係を利用するのではなく、商用利用が自由に認められているオープンソースライブラリを使用する場合は、自社の用途にとって十分に安全かどうかを徹底的に精査してください。どのくらいの頻度で更新されているか、また脆弱性がどれほど迅速に修正されているかを調べましょう。

最後に、正しいライブラリやソフトウェアコンポーネントを使用していることを必ず確認してください。攻撃者は、出所を十分に確認せずに自社のアプリケーションへ取り込んでくれることを期待して、よく似た名前の依存関係をアップロードすることがよくあります。

4. SBOMを作成・活用する

SBOMは、ソフトウェアサプライチェーンセキュリティにおいて極めて重要な役割を果たします。SBOMとは、アプリケーションを構成するすべてのコンポーネント・依存関係・ライブラリ・APIなどを網羅したインベントリー（一覧）です。さらに、バージョンやリリース情報、ソフトウェアライセンス、開発者情報なども含まれます。

SBOMはソフトウェアサプライチェーンに透明性と可視性をもたらし、組織がセキュリティ脆弱性を発見・修正できるようにします。

自社のアタックサーフェス（攻撃対象領域）を把握するために、提供元やサプライヤーと話し合い、そのソフトウェアやコンポーネントに含まれるすべてのライブラリ・依存関係の詳細情報を記載したSBOMを提供してもらいましょう。

これらのSBOMが、ソフトウェアに変更が生じるたびに更新されるようにしてください。SBOMを最新の状態に保つことは、どこに脆弱性が存在し、どの脆弱性がすでに修正済みかを把握するうえで不可欠です。

SBOMにVulnerability Exploitability eXchange（VEX）を組み込むことも検討しましょう。VEXは脆弱性が悪用可能かどうかに関する情報を提供するもので、これはリスク管理プロセスに反映させるべき要素です。

5. ランタイムセキュリティと監視を活用する

サプライチェーン攻撃が組織に深刻な被害をもたらす前に発見するうえで、検知と対応は重要です。早期検知が重要であり、それは静的スキャンだけでは十分ではないことを意味します。

そのため組織は、クラウドワークロードを継続的に監視・保護するランタイムセキュリティを導入する必要があります。ランタイムセキュリティは、マルウェア、コードインジェクション攻撃、ゼロデイ攻撃などに対するリアルタイムの脅威検知を提供します。

より多くの攻撃者が、コンテナや仮想マシンをはじめとするワークロードを動的な攻撃で狙うようになっているため、侵害の痕跡（IoC）を継続的に監視することが不可欠です。

ランタイムセキュリティは、実行時に脅威や不審・異常な振る舞いを特定します。CI/CDパイプラインにランタイム保護を組み込み、ソフトウェアコンポーネントや依存関係が不審な動作を始めた場合に検知できるようにしましょう。

6. 脆弱性や弱点をテストして修正する

セキュリティ対策・統制と、サードパーティのサプライヤーや提供元からの自己認証がそろったら、いよいよそれらを実際に試す段階です。自社のツールやシステムが不審な挙動を検知できるか、そして必要なアラートを生成できるかを確認する必要があります。

ペネトレーションテストなどのセキュリティテストを用いて攻撃をシミュレートし、攻撃者がアカウントの認証情報を盗み出した場合に自社の防御がどの程度持ちこたえるかを確認しましょう。ペネトレーションテストによって、サードパーティのサプライヤーが侵害された場合に攻撃を検知・緩和できるかどうかが明らかになります。

セキュリティテストは、サードパーティベンダーのセキュリティについて抱きがちな次のような疑問に答えてくれます：

• そのベンダーのIAM統制はどの程度強固か？
• ハードウェアの依存関係はどの程度安全か？
• APIのセキュリティは十分な水準にあるか？
• 過剰な権限を持つユーザーアカウントは存在しないか？

どこに弱点があるかを把握したら、時間をかけて、自社で制御できるものを修正するとともに、サードパーティのセキュリティ欠陥を悪用する攻撃を緩和するためのより優れた防御策を導入しましょう。

7. インシデント対応を準備する

前述のとおり、すべての攻撃を防ぐことはできません。そのため、脆弱性やその他のセキュリティ脅威が発見された後に、組織が迅速に行動できる体制を整えておく必要があります。その方法の一つが、インシデント対応のプレイブックを作成し、それを実践しておくことです。

インシデント対応プレイブックを策定し、関係するすべてのステークホルダーと意思決定者を巻き込みましょう。脆弱性が特定された場合や攻撃が検知された場合に、どのように対応するかを定めておきます。

プレイブックを用意したら、実際の攻撃時に関与することになるメンバーとともにセキュリティ演習を実施します。演習を繰り返し行い、全員が十分に準備できていると感じ、対応時間を短縮するために自分の役割を理解している状態にしましょう。

インシデント後の振り返りでは、プレイブックがどの程度うまく機能したか、あるいはどこが機能しなかったかを検証します。そこで得られたフィードバックを活用して、次回に向けてインシデント対応を改善しましょう。

サプライチェーンセキュリティについてさらに詳しく

組織への攻撃経路としてサードパーティベンダーを狙う攻撃者がますます増えているなか、ソフトウェアサプライチェーンセキュリティを整備しておくことが重要です。

サプライチェーン攻撃から組織を守る方法について基礎を理解し、アドバイスを得るには、当社のソフトウェアサプライチェーンセキュリティのガイドをご活用ください。ソフトウェアサプライチェーンセキュリティのその他のベストプラクティスについても学べます。

Sysdigは、 Falco およびSysdig Secureによってランタイムで不審なアクティビティを検知し、サプライチェーン攻撃から組織を守るお手伝いをします。また、当社の脆弱性管理ソリューションは、パイプライン内・レジストリ・ランタイムのいずれにも適用でき、セキュリティ脆弱性を発見できます。

サプライチェーンセキュリティの脅威を発見し、同じスピードで修正できるという確かな安心感を手にしてください。and . Our vulnerability management solution

‍