Merge pull request #413 from owada-k/patch-for-SBOM_QG_5.8

Patch for SBOM qg 5.8

Author: NorioKobota

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

@@ -408,23 +408,40 @@ SBOMの信頼性と改ざん耐性を確保するために、以下の改善策
 担当: 大和田さん  
 
 ##### 5.8.1. 課題の概要
-- コンポーネント間の依存関係や関連性（例：dependsOn、contains、generates等）の統一的記述ルールを定義し、テンプレートおよび自動検証ツールによる整合性チェックの方法を明示する。  
+コンポーネント間の依存関係や関連性については、多様な記述方法が許されているため、提供者と受領者間でSBOMに記載されている内容の誤認が生じ、システム全体のリスク評価や連携に支障が出ている。依存関係の記述方法についてサプライチェーン上での統一的な記述ルールの策定や、それを支えるテンプレートおよび自動検証ツールの導入が必要である。
 
 ##### 5.8.2. 課題の詳細
-- コンポーネント間の関係性の記述表記は非常に多くあり、どの表記を選択するかが人によって異なる
-- 同じ関係性に対して複数の表記がある
-- 同じ表記が複数の関係性に使われる
-- そのため、SBOMを提供者と受領者で表記が異なり、効果的な利用を妨げてしまう
+あるソフトウェアを利用するにあたって、ライセンス上の問題がないこと、脆弱性等の問題を含んでいないことを確認するために、そのソフトウェアがどのようなソフトウェアコンポーネントから成り立っているか、そして、それらのコンポーネントがどのように結合されているか、誰が加工したものかなどを把握することが必要となる。
+その情報を記述するために、SBOMでは、直接の構成要素であるソフトウェアコンポーネントだけでなく、必要とするライブラリ、開発ツール、開発者等もSBOMエレメントとして列挙し、さらに、これらの関係を記述するようになっている。
+しかしながら、複雑度や規模の様々なソフトウェアを対象とするため、関係性の記述に次のような課題が生じている。
+
+- 表記の多様性と頻発する不整合
+  - コンポーネント間の関係性（例：dependsOn、contains、generates等）の記述方法が多岐にわたり、どの表記を用いるかが担当者によって異なる。
+  - 同じ関係性に対して複数の表記が使われるため、統一性が欠如し、混乱が頻繁に発生している。
+- 表記の多義性による誤解
+  - 一つの表記が異なる関係性に使用されるケースがあり、提供者と受領者間で解釈のずれや誤認が生じ、リスク評価に影響を与えている。
+
+正確で有効に活用できるSBOMの作成には、サプライチェーン上のすべての組織の協力が不可欠であり、それぞれの組織が作成するSBOMの記述をそろえ、上記の課題を軽減することで、組織内・組織間でのSBOMの作成と活用の効率化・効果向上を図ることが望まれる。
 
 ##### 5.8.3. 改善策
-- 一般的な関係性について、標準となる表記を提案し、表記のブレが少なくなることを促す
-- 等価な関係性表記を標準的な表記に置き換えるツールや複数の関係性に使われる表記を見つけるツールを用意する
-- 標準となる表記の提案 [SPDX / CycloneDX]
+定義されている関係性を見ると、contains, depensOn, generatesなどの基本的な関係性を記述するものと、リンク形式や利用ツールを示すといった詳細な関係性や付加情報としての関係性を記述するものがある。
+そこで、関係性の記述のうち、次をPrimaryな関係性記述と定め、Primaryな関係性は必ずSBOMに記載することを提案する。
+
+- Primaryな関係性の提案 [SPDX / CycloneDX]
   - コンポーネントの現在の状態を記述するもの
     - contains/composition-assemblies：～を含む（構成される）
     - dependsOn/composition-dependencies：～に依存する（を必要とする）
   - コンポーネントの由来を記述するもの
     - generatedFrom*：components-pedigree：～生成された（複製された、改変された、ビルドされた）[* SPDX のVocabulariesには存在しない]
+
+これらのPrimaryな関係性を用いる事例を以下に示す。
+
+<作成メモ：ここにソフトのビルドフロー図とそれに対応する関係性記述を示す>
+
+この対応により、最低限必要な関係性が記述され、また、その表記のブレが少なくなることを促す。
+
+参考情報として、SPDX 3.0.1の関係性記述を分類した結果、および、CycloneDX 1.6における関係性の記述方法の概要を以下に示す。
+
 - 【参考１】[SPDX Specification Version 3.0.1 relationshipType](https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/RelationshipType/)分類
   - コンポーネントの現在の状態を記述するもの
     - ～を含む（構成される）
@@ -507,11 +524,13 @@ SBOMの信頼性と改ざん耐性を確保するために、以下の改善策
 
 
 ##### 5.8.4. 評価方法
-- ツールによる修正量や検出量を評価指標とする
+Primaryな関係性の記載漏れが少なくなることが評価指標と考える。
+そこで、Primaryな関係性と等価や類似性のあるな関係性表記だけが記載されており、Primaryな関係性の記載がないことを検出するツールが望まれる。
+また、複数の関係性に使われる表記を見つけ注意を促すツールが望まれる。
 
 ##### 5.8.5. リスクと留意事項
-- プログラム言語やビルド手法、ソフトウェアの管理手法の進化に伴い、新たな関係性が生まれ、標準と定めた表記では適切な表現ができなくなる可能性がある
-- その点を鑑み、厳格な運用ではなく、自由度のある対応を可能とする形とする方が良い 
+なお、この提案は、Primaryな関係性以外の記載を禁じるものではない。特に、Primaryな関係性と等価、あるいは、包含関係や類似性のある関係性表記を禁じるものではなく、それらの表記を残したままで、Primaryな関係表記を追加すれば良い。
+さらに、プログラム言語やビルド手法、ソフトウェアの管理手法の進化に伴い、新たな関係性が生まれ、Primaryと定めた表記では適切な表現ができなくなる可能性がある。その点を鑑み、厳格な運用ではなく、自由度のある対応を可能とする形としたい。
 
 #### 5.9 依存関係把握とパッケージ取得手法の問題
 担当: 伊藤さん