セキュリティアドバイザリに関する記述を削除

Author: itahoso

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

@@ -199,31 +199,37 @@ SBOMの交換フォーマットの仕様によりパッケージとファイル
 担当: 武山さん
 - バイナリ提供時にもソースファイル一覧、ハッシュ値、ライセンス情報など補完すべき情報を必須項目化するなど、自動抽出プロセスを導入する方針を示す。
 
-#### 5.4 脆弱性管理及びセキュリティリスク管理の強化  
+#### 5.4 脆弱性管理への適用
 担当: 細見さん  
 <!-- （細見）セクションのタイトルにあった「脆弱性連携」という言葉があまりポピュラーでないことと内容が限定的に思われたため、「脆弱性管理」に変更しています -->
 
 ##### 5.4.1. 課題の概要
-ソフトウェア製品のコンポーネント単位での脆弱性管理やセキュリティリスク管理を強化するために、SBOMの次のような情報が活用できる。しかし、これらは必ずしも正確かつ網羅的に記述できない。
+ソフトウェア製品のコンポーネント単位での脆弱性管理やセキュリティリスク管理を強化するために、SBOMの次のような情報が活用できる。しかし、これらは必ずしも正確かつ網羅的に記述されていない。
 1. 各コンポーネントの脆弱性の有無を知るために脆弱性情報と照合可能な、コンポーネント識別情報
 2. 見つかった脆弱性を報告したり対処を依頼するための、コンポーネントの提供者情報
 3. 見つかった脆弱性が他のコンポーネントに及ぼす影響を把握するための、コンポーネント間の依存関係
+<!--
 4. 脆弱性がソフトウェア製品に及ぼす影響の有無や対処のステータスを記した、セキュリティアドバイザリ
+-->
 
+（4番目のセキュリティアドバイザリの項目削除に合わせて図も更新予定）
 ![Vuln Management](images/fig5.4-1.png)
 <div align="center">脆弱性管理の流れ</div>
 
 ##### 5.4.2. 課題の詳細
 <!-- 対象課題の現状と理想状態を簡潔に説明, 図示しても良い -->
-SBOMの中で脆弱性管理およびセキュリティリスク管理に利用される情報には、それぞれ次のような課題がある。
+SBOMの中で脆弱性管理に利用される情報には、それぞれ次のような課題がある。
 1. コンポーネントの識別情報にコンポーネントの名前とバージョンを使用する場合、5.1.2節で例示されたような名前の表記揺れが生じ、脆弱性の検出漏れに繋がる。PURLやCPE名などの一意な識別子を記載しても、照合先の脆弱性データベースに記載されていない場合がある。
 2. 特にツールで生成されたSBOMの提供者情報は、未記載であったり、組織や個人が特定し難い記述になっている、名前のみで連絡用アドレスがないなど、問合せに利用できない場合がある。<br>
 （コンポーネントの提供者情報：JSON形式の場合、SPDX v2.3では packages[].supplier, SPDX v3.0では@graph[].suppliedBy,CycloneDXではcomponents[].supplier）
 3. ツールの種類や設定、またはソフトウェア製品の開発言語や開発環境によって、コンポーネント間の依存関係が網羅的に取得できない場合がある。
+
+<!--
 4. セキュリティアドバイザリの記述手段としてCSAF[^CSAF]やVEX[^VEX]があるものの、フォーマットや配布方法などが定まっておらず、対応しているツールや情報を提供しているサプライヤも少ない。
 
 [^CSAF]: Common Security Advisory Framework, https://www.csaf.io
 [^VEX]: Vulnerability Exploitability eXchange, https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf
+-->
 
 ##### 5.4.3. 改善策
 <!-- 問題解決のための具体的な対策（例：自動チェックツール導入、記述ルールの統一）-->
@@ -234,12 +240,17 @@ SBOMの中で脆弱性管理およびセキュリティリスク管理に利用
 1. OSV[^OSV]やNVD[^NVD]など、利用する脆弱性データベースに登録されているソフトウェアの名前や同様の表記方法を用いてコンポーネントの名前を記述する。また、それぞれの脆弱性データベースで採用されているソフトウェア識別子をコンポーネント情報に付与する（例えばOSVならばPURL、NVDならばCPE名）。
 2. コンポーネントの提供者情報には、可能な限り実在し且つ公表されていることを確認した上で組織や個人の名前、および有効なE-mailアドレスやURLなどの問合せ先情報を記載する。
 3. パッケージマネージャからコンポーネント間の依存関係を取得できるツールを利用し、依存関係を含んだSBOMを生成する。また、可能な限りSBOMを生成可能なビルドツールを用いてCISAのSBOM Type分類[^SBOMType]におけるBuild SBOMを生成する。
+
+<!--
 4. 対象のコンポーネントに関するセキュリティアドバイザリの情報が公開されている場合は、SBOMに外部参照情報として記載する。相当する情報はあるが機械可読ではない文章の場合は、VEXの必要最小限の情報を記述できるOpenVEXのフォーマット[^OpenVEX]で外部参照情報を作成すると良い。SPDX v3.0以降やCyclondDX v1.4以降では、SBOMと同じドキュメント内に記載することもできる。
+-->
 
 [^OSV]: A distributed vulnerability database for Open Source, https://osv.dev
 [^NVD]: National Vulnerability Database, https://nvd.nist.gov
 [^SBOMType]: Types of Software Bill of Materials (SBOM), https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom
+<!--
 [^OpenVEX]: OpenVEX, https://openssf.org/projects/openvex/
+-->
 
 <!--
 前述した各課題への基本的な対応方法は次の通り。
@@ -290,8 +301,10 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
 3. コンポーネント間の依存関係の精度評価
 - 依存関係も、コンポーネントの識別情報と同様に期待値としての精度を評価しておくと良い。SBOM生成ツールにおいて、パッケージマネージャを用いた依存関係抽出では高い精度を期待できるが、コード解析による抽出では誤検出や検出漏れの可能性がある。
 
+<!--
 4. セキュリティアドバイザリの調査
 - VEXなどの機械可読な形式のセキュリティアドバイザリは、まだ限られた一部のソフトウェアベンダーが提供している程度だが、特に脆弱性発見の頻度が高いソフトウェアについては提供者のセキュリティ情報サイトなどでアドバイザリまたはこれに相当する情報がないか確認する。
+-->
 
 ##### 5.4.5. リスクと留意事項
 <!-- 改善策実施に伴うリスク、例外対応、補足事項 -->
@@ -312,8 +325,10 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
   - SBOMに記述されたコンポーネント間の依存関係は、実際に動作しているソフトウェアにおける依存関係とは必ずしも一致しない。その理由としては、依存関係抽出の精度不足のほか、動的に読み込まれるコンポーネントに関する依存関係が記載されていない場合や、逆にソフトウェアの実行時に一部のコンポーネントが利用されない場合などがある。
   - 特に、ビルドツールでSBOMを生成できない場合、ソースコードやバイナリコードの解析によって生成されたSBOMにおけるコンポーネント間の依存関係には、高い精度や網羅性を期待し難い場合がある。
 
+<!--
 4. セキュリティアドバイザリについて
   - 膨大な数のコンポーネントで構成されたソフトウェアでは同時に大量の脆弱性が検出される場合がある一方、その大半に即時の対応を要するケースは相対的に少なく、適切なトリアージが必要である。しかし、まだ大半のコンポーネントについてVEXのような定型で機械可読なセキュリティアドバイザリが提供されていない現状では、脆弱性の影響有無や対処手段を一括で取得し管理することが容易でないため、過去に判断を保留したものを含めて脆弱性対応のためのアップデータの適用等に見落としが無いか注意する必要がある。
+-->
 
 
 #### 5.5 上流・下流間の情報統合と連携強化