こんにちは。継続的な脆弱性管理SaaS「FutureVuls」を運営している たけし です。

本記事は、2024年10月22-23日に開催された SOSS・Fusion/24の講演 Open Source Software (OSS) Transparency for Acquisition - Scott Hissam, Carnegie Mellon（約34分）では、米国防総省(DoD)の調達プロセスを例にソフトウェアサプライチェーンリスクの現状や、Acquisition Security Framework（ASF） の有用性が解説されています。

本記事では、主なポイントを整理し直し、以下のような疑問に答えられる形を目指しました。

• サプライチェーンリスクはなぜ深刻化しているのか？
• 「1つの脆弱性でも十分」というけれど、具体的にどう対策すればいい？
• ASF（Acquisition Security Framework）とは何か？
• GQIM（Goal–Question–Indicator–Measure）とは何か？ そして、なぜASFとGQIMを組み合わせる必要があるのか？
• 形だけのSBOMでは意味がないって本当？
• 日本企業や組織での導入時に気を付けることは何か？

注釈：以下の記事中では、動画内で頻出する専門用語や米国特有の用語について、引用ブロック（灰色枠）で補足を入れています。日本にはあまり馴染みがないので、わかりやすく説明していますのでご参照ください。

なお、日本独自の下請け構造やOSS利用事情は筆者が補足したもので、動画内で直接言及されているわけではありません。

1. サプライチェーンリスクの大枠：なぜ問題になるのか

ソフトウェア調達や開発のプロセスにおいて、外部ベンダーやOSSなどの“供給源”が複数あり、しかも深い依存関係で結ばれていることがリスク要因です。
講演動画の冒頭（約0:00～5:00) では、米国防総省(DoD)の調達を例に「多数のドキュメントや契約、資金が動いているが、実際にサプライチェーンリスクを体系的に監視できていない」という現状が紹介されました。

注釈：「DoD（Department of Defense）」は米国国防総省のこと。日本の防衛省と類似の役割を担い、大規模な軍事調達や研究開発を行っている。

1-1. 3D（Documentation, Data, Dollars）に隠れてしまうリスク

約1:00～2:00

DoD調達では、この3つに注目が集中し、ソフトウェアサプライチェーンがどのような依存構造になっているかは後回しにされがちと指摘。日本でも、形式的な書類契約や資金管理にフォーカスして、実際に誰がどのOSSを使っているかを追いきれない問題があります。

注釈：「サプライチェーンリスク」は、ソフトウェアや部品を含む複数の供給元（サプライヤー）が存在する中で発生するセキュリティや品質上のリスクを指す。企業や官公庁が製品を調達する際、下請け業者やOSSコミュニティを含めた全体の透明性が重要になる。

2. 「1つの脆弱性でも十分」──具体例から見るリスクの深刻度

2-1. F-35戦闘機の巨大コードベースと潜む脆弱性

約10:00～11:00

講演では、F-35戦闘機の3,500万行に及ぶコードを例に、一般的なバグ率から推計すると数万～数十万の不具合があり、さらにその一部（約5％）がセキュリティ脆弱性に繋がる恐れがあると試算されています。

日本でも100万行超の業務システムは珍しくないため、「行数×バグ率」でイメージしやすいインパクトが得られるかと思います。

注釈：「F-35戦闘機」は米国の最新鋭ステルス機であり、戦闘機としては異例の大規模ソフトウェアを搭載している。軍事用途ゆえに高度な機能と厳しい信頼性が求められるが、その分コード量が莫大になり、管理も困難化している。

2-2. 「One vulnerability is enough」

約11:00～11:30

たとえ脆弱性が多数でなくても、システムのコア部分（認証・暗号・ミドルウェアなど）に1つ深刻な脆弱性が潜んでいるだけで、全体が崩れる可能性がある点も強調されています。

「23万を超える企業のうちの 98% が、直近２年間で侵害をうけた組織と取引がある」というレポートからわかるように、取引先（サプライチェーン）が侵害されて攻撃者が利用可能な危険な脆弱性が１つでもあれば、攻撃者にとっては十分ともいえます。自組織の対策が完璧でもサプライチェーンが脆弱な状態であれば自組織も脆弱になります。

注釈：「Log4j脆弱性（Log4Shell）」は 2021年末に公表された深刻な脆弱性で、Javaで広く使われるログライブラリの脆弱性が世界的に波及し、多数の企業システムが同時に危険にさらされた例。まさに「1つの脆弱性」が大問題に発展したケース。

3. 「Turtles all the way down」──OSS依存の無限連鎖

約8:00～11:00

ソフトウェアはコンパイラやテストツールを含めた多数のパイプラインで作られますが、それらのツール自体もさらに別のOSSやベンダー製ソフトに依存…という「無限連鎖」が起こっています。

注釈：「It’s Turtles all the way down」は「亀の背中に地球が載っている」という古い比喩が転じて「どこまでも深い依存が続く」という意味合いで使われる。ソフトウェア開発でも、依存ライブラリやツールチェーンが別のものに依存し続ける様子を指す。

4. Shift Left の重要性──SDLC初期で潰すとコスト減

約11:00～14:00

ソフトウェア開発ライフサイクル（SDLC）の早い段階（要件定義・設計）で脆弱性を潰しておかないと、後工程（運用フェーズなど）で修正する際にコストが爆発する事例が語られます。
欠陥の多くは初期段階（要件定義や設計）で導入される一方、実際に発見されるのは統合テストや運用など後工程が多いという点がポイントです。その結果、欠陥の修正が遅れるほどコストやリスクが増大しやすく、全体の一部が脆弱性へと発展する可能性もあります。さらに、運用時の欠陥密度（100万行あたりの不具合数）が「最上位クラス」「非常に良い」「平均的コード」で大きく差があるように、大規模ソフトウェアでは欠陥総数も多くなるため、初期からセキュリティと品質を意識するShift Leftが不可欠だとわかります。

注釈：「SDLC（Software Development Life Cycle）」はソフトウェアの開発から運用保守までを一連のプロセスとして捉えた概念。ウォーターフォール型からアジャイル型まで様々だが、初期段階で対策を盛り込むほど後からの修正コストが低減するのは共通の原則。

5. Acquisition Security Framework（ASF）とは？

ASFは、ソフトウェアサプライチェーンリスク管理のために米国のSoftware Engineering Institute（SEI）が開発した包括的フレームワークです。51個のゴールと334のプラクティスを備え、以下のような領域をカバーします。

• プログラム管理（Program Management）
• エンジニアリングライフサイクル（Engineering Lifecycle）
• サプライヤー依存管理（Supplier Dependency Management）
• 独立評価とコンプライアンス（Independent Assessment & Compliance）
• プロセス管理（Process Management）
• サポート（Support）

ASFは「どのフェーズでどんなリスク管理をすれば良いか」「サプライヤー評価をどう行うか」など、大枠のベストプラクティス集を提供しており、やるべきことの全体像を理解するのに役立ちます。

ASFの具体例：SDM.2.3 (Supplier Risk Management)

ASFのプラクティスの1例として、SDM.2.3: Supplier Risk Management を見てみましょう。
ここでは、サプライヤーリスクを継続的に管理するためのゴールと、それを確認する具体的な質問（Question）が定義されています。たとえば以下のようなイメージです。

こうした質問のリストを使いながら、サプライヤーを継続的にモニタリングし、リスクを発見するたびに契約見直しや対策を検討するといった運用がASFによって促進されます。

ASFの概要は、FutureVuls用語集 Acquisition Security Framework（ASF）とは？ サプライチェーンセキュリティのチェックリストを参照してください。

注釈：「SEI（Software Engineering Institute）」はカーネギーメロン大学に属する研究機関で、米国防総省(DoD)向けにソフトウェア工学・セキュリティ分野の支援を行っている。Acquisition Security Frameworkは、DoDや政府機関だけでなく民間企業にも応用可能な仕組みとして整備された。

6. GQIM（Goal–Question–Indicator–Measure）とは？

GQIMは、ソフトウェアやセキュリティの取り組みにおいて「何をどのように測定し、どう評価するか」を体系的に決める枠組みです。例えば「脆弱性対応を早めたい」という目標がある場合、

• Goal（目標）：脆弱性修正リードタイムを 7 日以内に
• Question（疑問）：今の修正日数はどれくらい？ 改善の妨げになっているのは何？
• Indicator（指標）：平均修正日数、未修正CVEの件数、コミュニティのIssue対応速度など
• Measure（測定）：CI/CDのログやSBOM履歴、脆弱性報告日時・パッチ日時などを自動集計

こうして、定量的な根拠を元に改善サイクルを回せます。

注釈：「GQIM」はGQM（Goal Question Metric）を拡張したもので、Indicatorを明示的に挟むことで、何を計測し、どんな指標でモニタリングするかが整理しやすくなっている。
論文: Implementing Goal-Driven Measurement (IGDM) SEMA Course (2019)

7. P4フレームワーク（Product / Project / Protection / Policy）とは？

P4フレームワークは、OSSや商用ソフトなどサードパーティ製品を評価する際に4つの観点（Product / Project / Protection / Policy）をチェックする仕組みです。ASFの「サプライヤー依存管理」領域と相性がよく、特にOSSや複数ベンダーを使う場面で、リスクを具体的に洗い出すのに役立ちます。

注釈：「Red Flag」とは「危険信号」を意味し、P4チェックで不備が見つかった場合にRed Flagとして一覧化し、対応を検討する。

P4の利点

• 単なる「品質チェック」だけでなく、コミュニティ活動や保護策、契約面まで幅広く評価できる
• OSSや商用ソフトを導入する際に、どの部分が危ないのかを視覚的に整理しやすい
• ASFのプラクティス（サプライヤー評価など）を深掘りする形で、細かいリスクを洗い出せる

8. ASF・P4・GQIMの関係性

講演後半でも3つの手法が紹介されています。なぜこれらを組み合わせると良いのか、まとめると以下のような役割分担があります。

1. ASF
   • サプライチェーンリスク管理の「全体方針」や「やるべきプラクティス」を提示（何をすべきかの羅列）。
   • 例：「ベンダーを評価する」「開発ライフサイクルでセキュリティ要件を入れる」など。

2. P4フレームワーク
   • OSSや商用ソフトを評価する際に、Product / Project / Protection / Policy の4視点でより具体的にチェック（どのように評価・監査するか）。
   • 例：コミュニティ活動度・ライセンスリスクなどを可視化→ Red Flagを検知。

3. GQIM
   • ASFとP4で洗い出した評価項目をどの指標(Indicator)で測り、どのデータ(Measure)を使い、どんな目標(Goal)にするかを数値化し、改善を回す。
   • 例：修正リードタイム、未修正CVE数、コミュニティ参加率など。

結果として、ASFが「やるべきこと全体を示す」、P4が「具体的な視点でソフトを評価する」、GQIMが「その評価や改善を数値管理する」形となり、サプライチェーンリスク管理が実行しやすく・継続的に行いやすくなります。

9. DevSecOpsと連携し、継続的にMeasure（測定）を行う

約17:00～20:00

3つのフレームワーク・手法（ASF、P4、GQIM）を現場で活かすには、DevSecOpsの自動スキャンやCI/CDログをMeasureとして活用するのがおすすめです。

• CI/CDビルド時に脆弱性スキャン→ GQIMのIndicatorに設定した項目を数値化→ ASFで定めたゴール（例: 脆弱性修正スピード）を達成しているか検証
• サードパーティOSSのリリースノートをP4フレームワークで評価→ GQIMで活動頻度やIssue対応速度をMeasure
• SBOMの更新履歴を週次で取得→ P4のPolicy部分やASFのサプライヤー管理に対応→ GQIMで“SBOMが正確か”を客観的データで検証

注釈：「DevSecOps」はDevOps（開発と運用の連携）にセキュリティ(SEC)を統合した手法。CI/CDパイプラインで自動脆弱性スキャンやセキュリティテストを組み込み、継続的に安全性を確保する。

10. SBOMは形だけじゃダメ──実際の検証が不可欠

動画の20:00〜23:00あたりでは、SBOM（ソフトウェア部品表）を提出させるだけで終わりではなく、その内容をきちんと検証（Verify）する必要性が強調されています。いわゆる「Buyer Aware」の姿勢を持ち、SBOMに漏れや誤りがないかを積極的に把握しないと、せっかくのリスク管理が不十分なままになってしまうという問題提起です。

動画で確認できるポイント：

• 米国政府（OMB 等）がSBOM普及を進めているものの、実務ではバージョン情報の欠落など不備が多い。
• 「Buyer Aware」という言葉を用いて、買い手側がSBOMの質（Complete and Effective かどうか）を積極的に検証すべきだと警鐘を鳴らしている。

たとえば、バージョンや依存関係が記載されていても更新頻度が低かったり、重要なコンポーネント情報が抜け落ちていたりすれば、いざ脆弱性が出たときに対応が後手に回る恐れがあるわけです。SBOMを導入する際は、「正確な情報を得られているか」を必ず確認し、適切な手法でリスクを可視化・管理することが不可欠であると、動画でも繰り返し言及されています。

11. まとめ＆提言──ASF・P4・GQIMを組み合わせ、Buyer Awareを徹底する

動画の最後（約29:00～エンディング）では、サプライチェーンリスク管理を継続して行う重要性が再度強調されます。ASF + P4 + GQIM という3つの手法を組み合わせれば、

1. ASFで「サプライチェーンリスク管理の全体像・プラクティス」を把握。
2. P4フレームワークでOSSやサードパーティ製品を4視点（Product/Project/Protection/Policy）から評価し、不備（Red Flag）をチェック。
3. GQIMで「具体的に何を測り、どう数値化し、Goalに到達しているか」を明示。DevSecOpsの自動ツールとも連携しやすい。

注釈：「Buyer Aware」は、ラテン語の「Caveat Emptor（買い手よ注意せよ）」より一歩進み、買い手（導入側）が積極的に情報を検証しリスクを把握するというニュアンスを持つ造語。

計測こそがリスク管理の土台

• 脆弱性修正リードタイムを測らなければ管理できない。
• SBOMの正確性を検証しなければ、形だけの書類で終わる。
• OSSコミュニティの活動頻度をウォッチしなければ、危険が放置されているかどうか分からない。

こうした「何を測るか」の部分を GQIM が提供し、「それをもとにどうOSSやサプライヤーを評価するか」を P4 が補い、「そもそもどんなリスク管理が必要か」を ASF が示す構図です。日本企業の多重下請け現場でも、3つを組み合わせることでサプライチェーンリスクの可視化・低減が期待できます。

おわりに

米国防総省(DoD)の例は大規模かつ複雑ですが、その問題構造は日本企業でも同様に起こり得ます。ASFによる全体像の把握とP4フレームワークによる製品・OSS評価、そしてGQIMを通じた定量測定を組み合わせることで、サプライチェーンリスクは大幅に可視化・管理しやすくなります。

• SBOMを適切なフォーマットで取得・検証する。
• DevSecOpsと連動し、脆弱性修正リードタイムやテスト結果をGQIMでモニタリングする。
• P4フレームワークでOSSや商用製品を多角的に評価し、危険信号があれば早めに対策を検討する。

参考リンク

FutureVulsでは、企業の脆弱性管理を支援するSaaSを通じて、こうした継続的なセキュリティ対策を導入しやすい環境をご提供しています。OSSや下請けを含む多層構造のソフトウェアでも安全に運用できるよう、ぜひ一度ご相談ください。