ソフトウェアサプライチェーンのリスク管理：実践ガイド

リスク管理とセキュリティの違い

ソフトウェアサプライチェーンセキュリティは、SBOM、依存関係の固定、ビルドの制限といった技術的な対策の集まりです。リスク管理はその上位に位置します。自社のビジネスがどのサプライヤーやコンポーネントに依存しているか、その1つが機能しなくなったら何が起きるか、そして労力を正しい場所に費やしてきたかを問います。

どのようなリスクがあるか

リスク	例	主な管理策
脆弱なコンポーネント	広く使われているライブラリの欠陥	SBOMと継続的な監視
悪意のあるコンポーネント	乗っ取られたパッケージやタイポスクワッティング	精査、新バージョン導入までの待機、外向き通信の制限
放棄されたプロジェクト	唯一のメンテナーが離れてしまった依存関係	健全性チェックと置き換え計画
ライセンスリスク	プロプライエタリ製品に含まれるコピーレフトのコンポーネント	ライセンスポリシー
ビルドの侵害	乗っ取られたGitHub Actionがシークレットにアクセス	固定、分離、最小権限
サプライヤーリスク	ベンダーの製品やアップデートが侵害される	評価、契約、サプライヤーからのSBOM
規制リスク	顧客や法律が、提示できないエビデンスを求める	リリースごとに保管する記録

6つのステップ

インベントリを作成する。自社で作る製品と購入するソフトウェアを一覧にします。自社でビルドするものについては、リリースごとにSBOMを保管します。見えないものは評価できません。
重要度で順位付けする。決済サービスに含まれるライブラリと、社内ツールに含まれるライブラリは同じではありません。露出度、扱うデータ、ビジネスへの影響で製品を評価します。
リスクを評価する。脆弱性、プロジェクトの健全性、ライセンス、そして各サプライヤーのセキュリティへの取り組みを確認します。最上位の層は深く、それ以外は軽く評価します。
対処する。リスクごとに、修正、置き換え、管理策の追加、受容のいずれかを決めます。受容したリスクには担当者と見直し日が必要です。
継続的に監視する。リスクは、自社側で何も変えなくても変化します。たとえばアドバイザリが公開されたときや、メンテナーが離れたときです。年1回の見直しではこれを見逃します。
報告する。経営層には、主要なリスク、露出の推移、受容したものを簡潔に示します。詳細は顧客や監査人から求められます。

サプライヤーの評価

質問票だけでわかるのは、サプライヤーが何を言っているかです。実際に何をしているかがわかるものを求めましょう。

製品のSBOM（フォーマットが明示され、更新を入手する手段があるもの）
脆弱性への対応方法と、顧客に知らせるまでの速さ
セキュリティ窓口と開示ポリシー
リリースのビルド方法と、リリースの出どころを示せるかどうか
1つのバージョンがセキュリティ修正を受けられる期間
購入する製品を対象とする認証と監査レポート

こうした要件は契約に盛り込みましょう。SBOMや通知期限は、インシデントの後よりも契約時に求めるほうがはるかに簡単です。

参照すべきフレームワーク

NIST SP 800-161は、サイバーセキュリティサプライチェーンリスク管理（C-SCRM）の主要な参照文書です。組織のあらゆるレベルで機能し、サプライチェーンのリスクをより広いリスク管理に組み込みます。
NIST SSDFはセキュアな開発プラクティスを扱っており、サプライヤーに、そして自社に求めることの基礎として適しています。
SLSAは、ビルドの信頼性について共通の言葉を提供します。
ISO/IEC 27001:2022には、ICTサプライチェーンのセキュリティ（附属書A 5.21）と技術的脆弱性（8.8）に関する管理策が含まれます。SBOMは必須ではありませんが、これらの管理策のエビデンスとして有効です。
NIS2は、第21条第2項(d)で、対象となる事業体に必要な措置としてサプライチェーンのセキュリティを挙げています。

それぞれのもとでSBOMが何を証明するかを管理策ごとに確認するには、ISO 27001、SOC 2、NIS2のエビデンスとしてのSBOMをご覧ください。

測定方法

意思決定につながる指標をいくつか選びます。

現行リリースのSBOMがある製品の割合
新たな重大な脆弱性について「影響を受けているか」に答えるまでの時間
露出期間：脆弱なバージョンが本番環境にあった期間
過去1年間に評価した最上位層のサプライヤーの割合
見直し日を過ぎた受容リスクの件数

CRACIが役立つところ

CRACIは、自社でビルドするソフトウェアについて、リスク管理プログラムに通常欠けているデータを提供します。GitHub Actionsの各ビルドが取り込んだものを、宣言ライセンスも含めてSBOMに記録し、リリースごとに保管してCycloneDXまたはSPDXで共有できます。出荷したものを監視し、どのビルドに脆弱なパッケージが含まれていたかを示すため、影響を受けていた期間を把握できます。また、ライセンスポリシーを適用し、ポリシーゲートでビルドをブロックすることもできます。CRACIによるソフトウェアサプライチェーンセキュリティとツールの比較をご覧ください。

サプライヤーの評価とリスク登録簿は、引き続きガバナンスツールと社内のチームが担います。

ソフトウェアサプライチェーンのリスク管理：よくあるご質問

ソフトウェアサプライチェーンのリスク管理とは何ですか？

オープンソースパッケージ、商用製品、SaaSサプライヤー、ビルドツールなど、自社で書いていないソフトウェアに起因するリスクを、組織が特定・評価・低減する取り組みです。

C-SCRMとは何ですか？

C-SCRMはサイバーセキュリティサプライチェーンリスク管理（cybersecurity supply chain risk management）の略で、NISTが使う用語です。主要なガイダンスはNIST SP 800-161で、組織のあらゆるレベルでサプライチェーン全体のサイバーリスクを発見・評価・低減する方法を扱っています。

ソフトウェアサプライチェーンの最大のリスクは何ですか？

脆弱なオープンソースコンポーネントや悪意のあるオープンソースコンポーネント、侵害されたビルドシステムやCIツール、放棄されたプロジェクト、ライセンスの問題、そして侵害を受けるサプライヤーです。

サードパーティリスク管理とはどう違いますか？

サードパーティリスク管理は通常、ベンダーを企業として捉えます。ソフトウェアサプライチェーンのリスク管理は、背後にベンダーのいないオープンソースプロジェクトも含め、コンポーネントやビルドプロセスのレベルまで踏み込みます。

誰が責任を負いますか？

一般的には、セキュリティまたはリスク管理の責任者がプログラムを定め、製品セキュリティ部門が自社でビルドするものを、調達部門やベンダー管理部門が購入するものを担当します。見つかった問題はエンジニアリングチームが修正します。