Merge pull request #408 from itahoso/master

Re-modified Section 5.4

Author: NorioKobota

subgroups/sbom-sg/outcomes/QualityGuide/SBOM-Document-Quality-Guide.ja.md

@@ -211,24 +211,46 @@ SBOMの交換フォーマットの仕様によりパッケージとファイル
 担当: 武山さん
 - バイナリ提供時にもソースファイル一覧、ハッシュ値、ライセンス情報など補完すべき情報を必須項目化するなど、自動抽出プロセスを導入する方針を示す。
 
-#### 5.4 脆弱性管理及びリスクマネジメントの強化  
+#### 5.4 脆弱性管理及びセキュリティリスク管理の強化  
 担当: 細見さん  
 <!-- （細見）セクションのタイトルにあった「脆弱性連携」という言葉があまりポピュラーでないことと内容が限定的に思われたため、「脆弱性管理」に変更しています -->
 
 ##### 5.4.1. 課題の概要
-ソフトウェアのコンポーネント単位での脆弱性管理は、SBOMを作成する主要な目的の１つである。この目的のためには、SBOMに記述されたコンポーネントと脆弱性情報とを正確に照合し、その結果検出された脆弱性があればその影響範囲を特定し、適切な対処とリスク管理を行なうことが求められる。
+SBOMを利用した、ソフトウェア製品のコンポーネント単位での脆弱性管理やセキュリティリスク管理の強化が期待されている。そのためには、SBOMに次のような情報が正確かつ網羅的に記載されていることが重要となるが、いずれも容易とは言い難い。
+1. 各コンポーネントの脆弱性の有無を知るために脆弱性情報と照合できる識別情報
+2. 見つかった脆弱性の報告や対処を依頼するための該当コンポーネントの提供者情報
+3. その脆弱性が他のコンポーネントに及ぼす影響を知るためのコンポーネント間の依存関係
+4. その脆弱性がソフトウェア製品に及ぼす影響の有無や状態を記したセキュリティアドバイザリ
 
 ##### 5.4.2. 課題の詳細
 <!-- 対象課題の現状と理想状態を簡潔に説明, 図示しても良い -->
-SBOMを利用した脆弱性管理が有効であるためには、特に次の３つの課題に取り組む必要がある。
-1. 公的機関や民間企業などが提供している脆弱性情報から、ソフトウェアを構成しているいずれかのコンポーネントに影響するものを確実に見つけ出すため、脆弱性情報に記載されたソフトウェアの識別情報と精度良く照合できるようにSBOMのコンポーネント情報を記述する。
-2. SBOMのコンポーネント情報と脆弱性情報との照合によってSBOMが表すソフトウェアに脆弱性が検出された場合に、その脆弱性を悪用したサイバー攻撃を受けた場合にどのコンポーネントにまで影響が及ぶかを調べるため、コンポーネント間の依存関係をSBOMに記述する。
-3. 判明した影響範囲を基に、脆弱性に対処するためのソフトウェアのアップデートに伴うサービスの一時停止や動作の不具合が生じる可能性と、脆弱性に対処しない期間にサイバー攻撃を受ける可能性や予想される被害とのトレードオフを踏まえたリスク管理を行なう。
+SBOMの中で脆弱性管理およびセキュリティリスク管理に利用される情報には、それぞれ次のような課題がある。
+1. コンポーネントの識別情報にコンポーネントの名前とバージョンを使用する場合、5.1.2節で例示されたような名前の表記揺れが生じ、脆弱性の検出漏れに繋がる。PURLやCPE名などの一意な識別子を記載しても、照合先の脆弱性データベースが対応していない場合がある。
+2. 特にツールで生成されるSBOMの提供者情報は、記載されていない、一般に知られていない略称や提供者ではない文字列が記載されている、連絡用アドレスがないなど、問合せに利用できない場合がある。
+3. ツールの種類や設定、またはソフトウェア製品の開発言語や開発環境によって、コンポーネント間の依存関係が取得できない場合がある。
+4. セキュリティアドバイザリの標準的な記述形式としてCSAFやVEXがあるものの、まだあまり普及しておらず、対応しているツールも少ない。
+
+| |
+|---|
+|このあたりに、SBOMと脆弱性情報との突合〜リスク管理の大まかなフロー図を入れようかと|
+| |
 
 ##### 5.4.3. 改善策
 <!-- 問題解決のための具体的な対策（例：自動チェックツール導入、記述ルールの統一）-->
 <!-- 改善策の実施手順の概要 -->
 
+上述の各課題は、それぞれ次のような対応により改善することができる。
+
+1. OSV[^OSV]やNVD[^NVD]など、利用する脆弱性データベースに登録されているソフトウェアの名前や同様の表記方法を用いてコンポーネントの名前を記述する。または、それぞれの脆弱性データベースに採用されているソフトウェア識別子を記載する（例えばOSVならばPURL、NVDならばCPE名）。
+2. コンポーネントの提供者情報には、実在し且つ公開されている組織や個人の名前、および有効なE-mailアドレスやURLなどの問合せ先情報を記載する。
+3. パッケージマネージャからコンポーネント間の依存関係を取得できるツールを利用し、依存関係を含んだSBOMを生成する。
+4. 見つかった脆弱性が影響するコンポーネントやその影響状態を記したVEXの情報がある場合は、SBOMに外部参照情報として記載する。フォーマットが対応していればSBOMとVEXを同じドキュメントに記載してもよい。[^VEX]
+
+[^OSV]: A distributed vulnerability database for Open Source, https://osv.dev
+[^NVD]: National Vulnerability Database, https://nvd.nist.gov
+[^VEX]: Vulnerability Exploitability eXchange, CycloneDX v1.4以降やSPDX v3.0以降ではそれぞれのフォーマットでSBOMとVEXの情報を１つのドキュメントとして記述可能
+
+<!--
 前述した各課題への基本的な対応方法は次の通り。
 
 1. 脆弱性情報と精度良く照合するためのコンポーネント情報の記述<br>
@@ -256,6 +278,7 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
     コンポーネント毎の脆弱性の有無とコンポーネント間の依存関係は、前述の1.と2.を用いて把握することができる。脆弱性の深刻度には、脆弱性データベースに記録されているCVSS（脆弱性の深刻度スコア）やEPSS（脆弱性が悪用される確率）などが使える。
     被害の程度は、実際の被害額を正確に見積もることが難しいため、３段階ほどのレベルを設定することが多い。<br>
     新たな脆弱性が見つかった場合、評価したリスクが大きい場合は即時対応を優先し、リスクが小さい場合は事業継続性やコストを考慮して優先度を判断する。
+-->
 
 <!-- 
 リスク管理では脆弱性データベースに登録されている様々な情報を利用してリスク分析を行なうが、セキュリティアドバイザリに関する内容（VEX等）をSBOMとは独立に記述するというポリシーの下ではSBOMに対する要件は限られているため、このガイドでは詳しく述べないこととした。
@@ -265,32 +288,36 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
 <!-- 改善効果を示す指標（例：チェックリストの項目とその達成率）-->
 <!-- 定量・定性評価の実施方法と評価サイクル -->
 上記それぞれの改善策については、次のような評価方法が考えられる。
-1. コンポーネント情報と脆弱性情報との照合の精度評価
-- まずはSBOMのチェックツールでコンポーネント識別情報の記述方法に問題がないことを確認する。
-- SBOMのコンポーネント情報と脆弱性情報との照合を、なるべく作成者の異なる多くのSBOMドキュメントと脆弱性情報で試行し、精度を確認する。精度は、適合率（正確さ）のほか、可能であれば再現率（網羅性）も計測する。
 
-2. コンポーネント間の依存関係の精度評価
-- 依存関係の精度も、評価指標として適合率と再現率が利用できる。<br>
-  SBOM生成ツールにおいて、パッケージマネージャを用いた依存関係抽出では高い精度を期待できるが、コード解析による抽出では誤検出（適合率の低下）や検出漏れ（再現率の低下）の可能性がある。
+1. コンポーネントの識別情報と脆弱性情報との照合精度の評価
+- SBOMのデータフォーマットに対応した検証ツールでコンポーネントの識別情報の記述形式に問題がないことを確認する。
+- SBOMのコンポーネント識別情報と脆弱性情報との照合を、なるべく作成者や作成ツールが異なる多くのSBOMドキュメントと脆弱性情報で試行し、精度を確認する。精度は、適合率（正確さ）のほか、可能であれば再現率（網羅性）も計測し、実用的な期待値となっているかを確認する。
+
+2. コンポーネントの提供者情報
+- SBOM生成ツールから出力されたコンポーネントの提供者情報についても、その組織名や個人名、連絡先の情報が存在するかどうかを、Web検索などによって確認する。
 
-3. リスク管理の適切性評価
-- リスク管理またはリスク評価の適切性を定量的に評価することは難しいため、チェックリストを用いた定期的な内部監査や、ペネトレーションテストなどによるサイバー攻撃への耐性評価を行ない、リスク管理の運用が適切に機能していることを確認する。
+3. コンポーネント間の依存関係の精度評価とセキュリティアドバイザリの調査
+- 依存関係も、コンポーネントの識別情報と同様に期待値としての精度を評価しておくと良い。SBOM生成ツールにおいて、パッケージマネージャを用いた依存関係抽出では高い精度を期待できるが、コード解析による抽出では誤検出や検出漏れの可能性がある。<br>
+- VEXは、まだ限られた一部のソフトウェアベンダーが提供している程度だが、セキュリティリスク管理に有用な情報であるため、ベンダーのセキュリティ情報サイトなどで確認しておく。
 
 ##### 5.4.5. リスクと留意事項
 <!-- 改善策実施に伴うリスク、例外対応、補足事項 -->
 それぞれの改善策には、次のようなリスクがあることに留意しておく。
-1. 脆弱性情報と照合するためのコンポーネント情報について
-  - 脆弱性情報との照合にコンポーネントの名前とバージョンを用いる場合、脆弱性情報に記載されているソフトウェアの名前の表記方法は、脆弱性情報の種類によって若干異なる場合がある。
-  - 脆弱性情報との照合にコンポーネントのCPE名を用いる場合、CPE名には表記揺れや重複が多く、まだ脆弱性が発見されていないソフトウェアにはCPE名が無い。
-  - 脆弱性情報との照合にコンポーネントのPURLを用いる場合、PURLが識別子として登録されている脆弱性データベースはまだ少ない。
+
+1. 脆弱性情報と照合するためのコンポーネントの識別情報について
+  - 脆弱性情報との照合にコンポーネントの名前とバージョンを用いる場合、脆弱性情報に記載されているソフトウェアの名前の表記方法は、脆弱性情報の種類によって若干異なる場合がある。また、ツールから出力されたコンポーネントの名前にも表記揺れが生じうる（5.1節参照）。
+  - 脆弱性情報との照合にコンポーネントのPURLを利用できる脆弱性データベースは、現状では一部に限られている（OSVはPURLに対応、NVDは未対応）。
   - いずれかのコンポーネントの実行時に動的に読み込まれるようなコンポーネントの情報はSBOMに記述されていない場合がある。
 <!-- また、PURLではバージョンがオプションとなっているが、これがないと脆弱性情報との一意な対応付けができないため、PURLが自動生成される場合もSBOMの全てのコンポーネントのPURLに（SBOM自体のバージョン属性やCPEにも）バージョンが記載されていることを確認する。それでも、バージョン記述の揺れによる照合ミスのリスクは残ることに留意すべき。-->
 
-2. コンポーネント間の依存関係について
+2. コンポーネントの提供者情報について
+  - コンポーネントの名前と同様に、提供者名も表記揺れによって一貫性が保たれない場合がある（5.1節参照）。
+  - コンポーネント（パッケージ）の提供者は、企業の買収や事業停止、個人の都合などによって、開発やサポートが停止していたり他者へ移っている場合がある。SBOMにEOL/EOS情報があるかの確認、アップデートや問い合わせ対応などの状況を見ておくことも、リスク管理の一環となる。
+
+3. コンポーネント間の依存関係とセキュリティアドバイザリについて
   - SBOMに記述されたコンポーネント間の依存関係は、実際に動作しているソフトウェアにおける依存関係とは必ずしも一致しない。その理由としては、依存関係抽出の精度不足のほか、上記のコンポーネント情報と同様に動的に読み込まれるコンポーネントに関する依存関係が記述されていない場合や、逆にソフトウェアの実行時に一部のコンポーネントが利用されない場合などがある。
+  - 膨大な数のコンポーネントで構成されたソフトウェアでは同時に大量の脆弱性が検出される場合がある一方、その大半に即時の対応を要するケースは少なく、適切なトリアージが必要である。しかし、まだ大半のコンポーネントについてVEXのような定型で機械可読なセキュリティアドバイザリが提供されていない現状では、脆弱性の影響有無や対処手段を一括で取得し管理することが容易でないため、過去に判断を保留したものを含めて見落としが無いか注意する必要がある。
 
-3. リスク管理について
-  - サイバーセキュリティのリスク管理やその評価は、いずれも人の判断に委ねられる部分が多いため、それらを実施する人の知識やスキルの不足、判断の揺れなどが影響する。
 
 #### 5.5 上流・下流間の情報統合と連携強化  
 担当: 余保さん