また少し更新。

Author: itahoso

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

@@ -205,9 +205,9 @@ SBOMの交換フォーマットの仕様によりパッケージとファイル
 
 ##### 5.4.1. 課題の概要
 ソフトウェア製品のコンポーネント単位での脆弱性管理やセキュリティリスク管理を強化するために、SBOMの次のような情報が活用できる。しかし、これらは必ずしも正確かつ網羅的に記述できない。
-1. 各コンポーネントの脆弱性の有無を知るために脆弱性情報と照合できる、コンポーネント識別情報
+1. 各コンポーネントの脆弱性の有無を知るために脆弱性情報と照合可能な、コンポーネント識別情報
 2. 見つかった脆弱性を報告したり対処を依頼するための、コンポーネントの提供者情報
-3. 見つかった脆弱性が他のコンポーネントに及ぼす影響を知るための、コンポーネント間の依存関係
+3. 見つかった脆弱性が他のコンポーネントに及ぼす影響を把握するための、コンポーネント間の依存関係
 4. 脆弱性がソフトウェア製品に及ぼす影響の有無や対処のステータスを記した、セキュリティアドバイザリ
 
 ![Vuln Management](images/fig5.4-1.png)
@@ -216,11 +216,11 @@ SBOMの交換フォーマットの仕様によりパッケージとファイル
 ##### 5.4.2. 課題の詳細
 <!-- 対象課題の現状と理想状態を簡潔に説明, 図示しても良い -->
 SBOMの中で脆弱性管理およびセキュリティリスク管理に利用される情報には、それぞれ次のような課題がある。
-1. コンポーネントの識別情報にコンポーネントの名前とバージョンを使用する場合、5.1.2節で例示されたような名前の表記揺れが生じ、脆弱性の検出漏れに繋がる。PURLやCPE名などの一意な識別子を記載しても、照合先の脆弱性データベースが対応していない場合がある。
-2. 特にツールで生成されたSBOMの提供者情報は、記載されていない場合や、組織や個人が特定し難い記述になっている、名前のみで連絡用アドレスがないなど、問合せに利用できない場合がある。<br>
-（コンポーネントの提供者情報：SPDX v2.3では packages[].supplier, SPDX v3.0では@graph[].suppliedBy,CycloneDXではcomponents[].supplier）
-3. ツールの種類や設定、またはソフトウェア製品の開発言語や開発環境によって、コンポーネント間の依存関係が取得できない場合がある。
-4. セキュリティアドバイザリの記述手段としてCSAF[^CSAF]やVEX[^VEX]があるものの、フォーマットや配布方法などが定まっておらず、対応しているツールも少ない。
+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
@@ -229,15 +229,16 @@ SBOMの中で脆弱性管理およびセキュリティリスク管理に利用
 <!-- 問題解決のための具体的な対策（例：自動チェックツール導入、記述ルールの統一）-->
 <!-- 改善策の実施手順の概要 -->
 
-上述の各課題は、それぞれ次のような対応により改善することができる。
+上述の各課題は、それぞれ次のような対策によって改善が期待できる。
 
-1. OSV[^OSV]やNVD[^NVD]など、利用する脆弱性データベースに登録されているソフトウェアの名前や同様の表記方法を用いてコンポーネントの名前を記述する。または、それぞれの脆弱性データベースに採用されているソフトウェア識別子を記載する（例えばOSVならばPURL、NVDならばCPE名）。
+1. OSV[^OSV]やNVD[^NVD]など、利用する脆弱性データベースに登録されているソフトウェアの名前や同様の表記方法を用いてコンポーネントの名前を記述する。また、それぞれの脆弱性データベースで採用されているソフトウェア識別子をコンポーネント情報に付与する（例えばOSVならばPURL、NVDならばCPE名）。
 2. コンポーネントの提供者情報には、可能な限り実在し且つ公表されていることを確認した上で組織や個人の名前、および有効なE-mailアドレスやURLなどの問合せ先情報を記載する。
-3. パッケージマネージャからコンポーネント間の依存関係を取得できるツールを利用し、依存関係を含んだSBOMを生成する。また、可能な限りSBOMを生成可能なビルドツールを用いてビルド時にSBOMを生成する。
-4. セキュリティアドバイザリの情報が公開されている場合は、SBOMに外部参照情報として記載する。相当する情報はあるが機械可読ではない文章の場合は、VEXの必要最小限の情報を記述できるOpenVEXのフォーマット[^OpenVEX]で外部参照情報を作成すると良い。また、SPDX v3.0以降やCyclondDX v1.4以降では、SBOMと同じドキュメント内に記載することもできる。
+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/
 
 <!--
@@ -284,13 +285,13 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
 - SBOMのコンポーネント識別情報と脆弱性情報との照合を、なるべく作成者や作成ツールが異なる多くのSBOMドキュメントと脆弱性情報で試行し、精度を確認する。精度は、適合率（正確さ）のほか、可能であれば再現率（網羅性）も計測し、実用的な期待値となっているかを確認する。
 
 2. コンポーネントの提供者情報
-- SBOM生成ツールから出力されたコンポーネントの提供者情報についても、その組織名や個人名、連絡先の情報が存在するかどうかを、Web検索などによって確認する。
+- SBOM生成ツールから出力されたコンポーネントの提供者情報についても、その組織名や個人名、連絡先の情報が存在するかどうかを、WebやSNSでの情報発信の有無と最新の発信日時などによって確認する。
 
 3. コンポーネント間の依存関係の精度評価
 - 依存関係も、コンポーネントの識別情報と同様に期待値としての精度を評価しておくと良い。SBOM生成ツールにおいて、パッケージマネージャを用いた依存関係抽出では高い精度を期待できるが、コード解析による抽出では誤検出や検出漏れの可能性がある。
 
 4. セキュリティアドバイザリの調査
-- VEXのようなセキュリティアドバイザリは、まだ限られた一部のソフトウェアベンダーが提供している程度だが、特に脆弱性発見の頻度が高いソフトウェアについては提供者のセキュリティ情報サイトなどでアドバイザリまたはこれに相当する情報がないか確認する。
+- VEXなどの機械可読な形式のセキュリティアドバイザリは、まだ限られた一部のソフトウェアベンダーが提供している程度だが、特に脆弱性発見の頻度が高いソフトウェアについては提供者のセキュリティ情報サイトなどでアドバイザリまたはこれに相当する情報がないか確認する。
 
 ##### 5.4.5. リスクと留意事項
 <!-- 改善策実施に伴うリスク、例外対応、補足事項 -->
@@ -299,19 +300,20 @@ CPE名に比べて表記揺れの可能性が低く、ソフトウェア開発
 1. 脆弱性情報と照合するためのコンポーネントの識別情報について
   - 脆弱性情報との照合にコンポーネントの名前とバージョンを用いる場合、脆弱性情報に記載されているソフトウェアの名前の表記方法は、脆弱性情報の種類によって若干異なる場合がある。また、ツールから出力されたコンポーネントの名前にも表記揺れが生じうる（5.1節参照）。
   - 脆弱性情報との照合にコンポーネントのPURLを利用できる脆弱性データベースは、現状では一部に限られている（OSVはPURLに対応、NVDは未対応）。
-  - いずれかのコンポーネントの実行時に動的に読み込まれるようなコンポーネントの情報はSBOMに記述されていない場合がある。
+  - NVDなどで採用されているCPE名には表記揺れが生じうる。同じコンポーネントが、表記の異なる複数のCPE名で脆弱性情報に紐付けられている場合がある。
+  - いずれかのコンポーネントの実行時に動的に読み込まれるようなコンポーネントの情報は、SBOMに記述されていない場合がある。
 <!-- また、PURLではバージョンがオプションとなっているが、これがないと脆弱性情報との一意な対応付けができないため、PURLが自動生成される場合もSBOMの全てのコンポーネントのPURLに（SBOM自体のバージョン属性やCPEにも）バージョンが記載されていることを確認する。それでも、バージョン記述の揺れによる照合ミスのリスクは残ることに留意すべき。-->
 
 2. コンポーネントの提供者情報について
   - コンポーネントの名前と同様に、提供者名も表記揺れによって一貫性が保たれない場合がある（5.1節参照）。
-  - コンポーネント（パッケージ）の提供者は、企業の買収や事業停止、個人の都合などによって、開発やサポートが停止していたり他者へ移っている場合がある。SBOMにEOL/EOS情報があるかの確認、アップデートや問い合わせ対応などの状況を見ておくことも、リスク管理の一環となる。
+  - コンポーネント（パッケージ）の提供者は、企業の買収や事業停止、個人の都合などによって、開発やサポートが停止していたり他者へ移っている場合がある。そうした動向の定期的な確認も重要である。
 
 3. コンポーネント間の依存関係について
-  - SBOMに記述されたコンポーネント間の依存関係は、実際に動作しているソフトウェアにおける依存関係とは必ずしも一致しない。その理由としては、依存関係抽出の精度不足のほか、動的に読み込まれるコンポーネントに関する依存関係が記述されていない場合や、逆にソフトウェアの実行時に一部のコンポーネントが利用されない場合などがある。
+  - SBOMに記述されたコンポーネント間の依存関係は、実際に動作しているソフトウェアにおける依存関係とは必ずしも一致しない。その理由としては、依存関係抽出の精度不足のほか、動的に読み込まれるコンポーネントに関する依存関係が記載されていない場合や、逆にソフトウェアの実行時に一部のコンポーネントが利用されない場合などがある。
   - 特に、ビルドツールでSBOMを生成できない場合、ソースコードやバイナリコードの解析によって生成されたSBOMにおけるコンポーネント間の依存関係には、高い精度や網羅性を期待し難い場合がある。
 
 4. セキュリティアドバイザリについて
-  - 膨大な数のコンポーネントで構成されたソフトウェアでは同時に大量の脆弱性が検出される場合がある一方、その大半に即時の対応を要するケースは少なく、適切なトリアージが必要である。しかし、まだ大半のコンポーネントについてVEXのような定型で機械可読なセキュリティアドバイザリが提供されていない現状では、脆弱性の影響有無や対処手段を一括で取得し管理することが容易でないため、過去に判断を保留したものを含めて見落としが無いか注意する必要がある。
+  - 膨大な数のコンポーネントで構成されたソフトウェアでは同時に大量の脆弱性が検出される場合がある一方、その大半に即時の対応を要するケースは相対的に少なく、適切なトリアージが必要である。しかし、まだ大半のコンポーネントについてVEXのような定型で機械可読なセキュリティアドバイザリが提供されていない現状では、脆弱性の影響有無や対処手段を一括で取得し管理することが容易でないため、過去に判断を保留したものを含めて脆弱性対応のためのアップデータの適用等に見落としが無いか注意する必要がある。
 
 
 #### 5.5 上流・下流間の情報統合と連携強化