Merge pull request #425 from itahoso/master

updated section 5.4

Author: NorioKobota

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

@@ -249,31 +249,40 @@ SBOM の提供者はバイナリコンポーネントに対して、次のよう
 
 SBOM受領者が、SBOM提供者がバイナリコンポーネントに付与されたソースコード情報の妥当性を検証する方法には課題がある。検証方法の1つとして、受領者が再度ビルドを行うことで、バイナリが一致するかを確認する方法がある。これを行うためには、ビルド環境の情報の提供と、ビルド再現性が担保されている必要がある。
 
-#### 5.4 脆弱性管理及びセキュリティリスク管理の強化  
+#### 5.4 脆弱性管理への適用
 担当: 細見さん  
 <!-- （細見）セクションのタイトルにあった「脆弱性連携」という言葉があまりポピュラーでないことと内容が限定的に思われたため、「脆弱性管理」に変更しています -->
 
 ##### 5.4.1. 課題の概要
-ソフトウェア製品のコンポーネント単位での脆弱性管理やセキュリティリスク管理を強化するために、SBOMの次のような情報が活用できる。しかし、これらは必ずしも正確かつ網羅的に記述できない。
+ソフトウェア製品のコンポーネント単位での脆弱性管理やセキュリティリスク管理を強化するために、SBOMの次のような情報が活用できる。しかし、これらは必ずしも正確かつ網羅的に記述されていない。
 1. 各コンポーネントの脆弱性の有無を知るために脆弱性情報と照合可能な、コンポーネント識別情報
-2. 見つかった脆弱性を報告したり対処を依頼するための、コンポーネントの提供者情報
+2. 見つかった脆弱性の通知先または対処の依頼先となる、コンポーネントの提供者情報
 3. 見つかった脆弱性が他のコンポーネントに及ぼす影響を把握するための、コンポーネント間の依存関係
+<!--
 4. 脆弱性がソフトウェア製品に及ぼす影響の有無や対処のステータスを記した、セキュリティアドバイザリ
+-->
 
-![Vuln Management](images/fig5.4-1.png)
+![Vuln Management](images/fig5.4-1_v2.png)
 <div align="center">脆弱性管理の流れ</div>
+<br>
+なお、脆弱性の詳細や対処状況も、VEX[^VEX]などの形式で記録することによって透明性を確保し変化の追跡ができる。VEXはSPDX v3.0以降やCycloneDX v1.4以降のフォーマットで記述可能だが、SBOMドキュメントの一部ではなく別のドキュメントとして扱う。
+
+[^VEX]: Vulnerability Exploitability eXchange, https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf
 
 ##### 5.4.2. 課題の詳細
 <!-- 対象課題の現状と理想状態を簡潔に説明, 図示しても良い -->
-SBOMの中で脆弱性管理およびセキュリティリスク管理に利用される情報には、それぞれ次のような課題がある。
+SBOMの中で脆弱性管理に利用される上記各情報の記述には、それぞれ次のような課題がある。
 1. コンポーネントの識別情報にコンポーネントの名前とバージョンを使用する場合、5.1.2節で例示されたような名前の表記揺れが生じ、脆弱性の検出漏れに繋がる。PURLやCPE名などの一意な識別子を記載しても、照合先の脆弱性データベースに記載されていない場合がある。
-2. 特にツールで生成されたSBOMの提供者情報は、未記載であったり、組織や個人が特定し難い記述になっている、名前のみで連絡用アドレスがないなど、問合せに利用できない場合がある。<br>
+2. 特にツールで生成されたSBOMでは、コンポーネントの提供者情報が、記載されていない、組織や個人が特定し難い表記になっている、名前のみで連絡用アドレスがないなどの理由から、問合せに利用できない場合がある。<br>
 （コンポーネントの提供者情報：JSON形式の場合、SPDX v2.3では packages[].supplier, SPDX v3.0では@graph[].suppliedBy,CycloneDXではcomponents[].supplier）
-3. ツールの種類や設定、またはソフトウェア製品の開発言語や開発環境によって、コンポーネント間の依存関係が網羅的に取得できない場合がある。
+3. SBOM生成ツールの種類や設定、またはソフトウェアの開発言語や開発環境によって、コンポーネント間の依存関係が網羅的に取得できない場合がある。
+
+<!--
 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. 改善策
 <!-- 問題解決のための具体的な対策（例：自動チェックツール導入、記述ルールの統一）-->
@@ -284,12 +293,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/
+-->
 
 <!--
 前述した各課題への基本的な対応方法は次の通り。
@@ -340,8 +354,10 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
 3. コンポーネント間の依存関係の精度評価
 - 依存関係も、コンポーネントの識別情報と同様に期待値としての精度を評価しておくと良い。SBOM生成ツールにおいて、パッケージマネージャを用いた依存関係抽出では高い精度を期待できるが、コード解析による抽出では誤検出や検出漏れの可能性がある。
 
+<!--
 4. セキュリティアドバイザリの調査
 - VEXなどの機械可読な形式のセキュリティアドバイザリは、まだ限られた一部のソフトウェアベンダーが提供している程度だが、特に脆弱性発見の頻度が高いソフトウェアについては提供者のセキュリティ情報サイトなどでアドバイザリまたはこれに相当する情報がないか確認する。
+-->
 
 ##### 5.4.5. リスクと留意事項
 <!-- 改善策実施に伴うリスク、例外対応、補足事項 -->
@@ -351,19 +367,21 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
   - 脆弱性情報との照合にコンポーネントの名前とバージョンを用いる場合、脆弱性情報に記載されているソフトウェアの名前の表記方法は、脆弱性情報の種類によって若干異なる場合がある。また、ツールから出力されたコンポーネントの名前にも表記揺れが生じうる（5.1節参照）。
   - 脆弱性情報との照合にコンポーネントのPURLを利用できる脆弱性データベースは、現状では一部に限られている（OSVはPURLに対応、NVDは未対応）。
   - NVDなどで採用されているCPE名には表記揺れが生じうる。同じコンポーネントが、表記の異なる複数のCPE名で脆弱性情報に紐付けられている場合がある。
-  - いずれかのコンポーネントの実行時に動的に読み込まれるようなコンポーネントの情報は、SBOMに記述されていない場合がある。
+  - いずれかのコンポーネントの実行時に動的に読み込まれるような外部コンポーネントの情報は、SBOMに記述されていない場合がある。
 <!-- また、PURLではバージョンがオプションとなっているが、これがないと脆弱性情報との一意な対応付けができないため、PURLが自動生成される場合もSBOMの全てのコンポーネントのPURLに（SBOM自体のバージョン属性やCPEにも）バージョンが記載されていることを確認する。それでも、バージョン記述の揺れによる照合ミスのリスクは残ることに留意すべき。-->
 
 2. コンポーネントの提供者情報について
   - コンポーネントの名前と同様に、提供者名も表記揺れによって一貫性が保たれない場合がある（5.1節参照）。
   - コンポーネント（パッケージ）の提供者は、企業の買収や事業停止、個人の都合などによって、開発やサポートが停止していたり他者へ移っている場合がある。そうした動向の定期的な確認も重要である。
 
 3. コンポーネント間の依存関係について
-  - SBOMに記述されたコンポーネント間の依存関係は、実際に動作しているソフトウェアにおける依存関係とは必ずしも一致しない。その理由としては、依存関係抽出の精度不足のほか、動的に読み込まれるコンポーネントに関する依存関係が記載されていない場合や、逆にソフトウェアの実行時に一部のコンポーネントが利用されない場合などがある。
+  - SBOMに記述されたコンポーネント間の依存関係は、実際に動作しているソフトウェアにおける依存関係とは必ずしも一致しない。その理由としては、依存関係抽出の精度不足のほか、動的に読み込まれるコンポーネントに関する依存関係が記載されていない場合や、逆に設定や環境の違いによってソフトウェアの実行時に一部のコンポーネントが読み込まれない場合などがある。
   - 特に、ビルドツールでSBOMを生成できない場合、ソースコードやバイナリコードの解析によって生成されたSBOMにおけるコンポーネント間の依存関係には、高い精度や網羅性を期待し難い場合がある。
 
+<!--
 4. セキュリティアドバイザリについて
   - 膨大な数のコンポーネントで構成されたソフトウェアでは同時に大量の脆弱性が検出される場合がある一方、その大半に即時の対応を要するケースは相対的に少なく、適切なトリアージが必要である。しかし、まだ大半のコンポーネントについてVEXのような定型で機械可読なセキュリティアドバイザリが提供されていない現状では、脆弱性の影響有無や対処手段を一括で取得し管理することが容易でないため、過去に判断を保留したものを含めて脆弱性対応のためのアップデータの適用等に見落としが無いか注意する必要がある。
+-->
 
 
 #### 5.5 上流・下流間の情報統合と連携強化