SBOM Quality Guide: Initial version of 5.3

Signed-off-by: Fuminobu TAKEYAMA <fuminobu.takeyama.h15@mail.toshiba>

Author: ftake

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

@@ -208,8 +208,42 @@ SBOMの交換フォーマットの仕様によりパッケージとファイル
 
 
 #### 5.3 ソース情報の補完と透明性向上  
-担当: 武山さん
+
+<!--
 - バイナリ提供時にもソースファイル一覧、ハッシュ値、ライセンス情報など補完すべき情報を必須項目化するなど、自動抽出プロセスを導入する方針を示す。
+-->
+
+##### 5.3.1. 課題の概要
+
+コンポーネントをバイナリ形式で授受する場合において、このコンポーネントのもととなったソースコードの情報が必要になることがある。コンポーネントの受領者が、受領したライセンス情報を検証したり、コンポーネントが脆弱性の影響を受けるかどうかを検証したりする際に、ソースコードが主な情報源となるからである。
+
+SBOM にソースコードの情報を付与し、サプライチェーンの透明性を高める必要がある。
+
+
+##### 5.3.2. 課題の詳細
+
+コンポーネントを識別する方法として用意されているサプライヤー名、コンポーネント名、バージョンを使用すれば、コンポーネントが OSS である場合にには、GitHub などのソフトウェアリポジトリからソースコードを見つけ出せることもある。しかしながら、一般に、バイナリコンポーネントを作成する際に、カスタマイズや脆弱性や不具合を修正するためのコードの変更（パッチ）を行うことがあり、このような場合には厳密なソースコードを特定できない。
+
+また、同じコンポーネント、バージョンであっても、ソースコードリポジトリ内のファイルと、リリース成果物として公開されている tar.xz ファイルの内容が一致しないことがあり、ビルドに使用した厳密なソースコード情報を残しておく必要がある。
+
+##### 5.3.3. 改善策
+
+SBOM の提供者はバイナリコンポーネントに対して、次のようにソースコードの情報を付与することで、サプライチェーンの透明性を向上することができる。
+
+* バイナリコンポーネントのソースコードを、ソースコード形式のコンポーネントとして SBOM に追加し、ソースコード情報を管理する。SPDX ではバイナリコンポーネントとソースコード形式のコンポーネントを `GENERATED_FROM`, `DECENDANT_OF`, `CONTAINS` などで関連付けることができる（5.8も参照）。
+* CycloneDX では、コンポーネントのソースコード情報を保持するための仕組みとして `pedigree` 属性を持ち、バイナリコンポーネントに対して直接ソースコード情報、パッチ情報を記載することもできる。
+* ソースコード情報には以下の情報を含める。
+    * （一般に入手可能である場合）入手元のURL。tar.xz ファイルの URL やバージョン管理システムへの URL でもよい。
+    * ソースコードのハッシュ値。tar.xz ファイルであれば、このファイルの SHA-512 ハッシュ値、バージョン管理システムであればコミットハッシュを使用する。SWHID も利用できる。
+    * ビルド時に変更を加えた場合は、パッチの情報をソースコードと同様に含める必要がある。
+
+##### 5.3.4. 評価方法
+
+すべてのバイナリ形式のコンポーネントについて、改善策で示した方法でソースコード形式のコンポーネントを付与することをルール化することで、バイナリコンポーネントの透明性を定量的に評価することができるようになる。
+
+##### 5.3.5. リスクと留意事項
+
+SBOM受領者が、SBOM提供者がバイナリコンポーネントに付与されたソースコード情報の妥当性を検証する方法には課題がある。検証方法の1つとして、受領者が再度ビルドを行うことで、バイナリが一致するかを確認する方法がある。これを行うためには、ビルド環境の情報の提供と、ビルド再現性が担保されている必要がある。
 
 #### 5.4 脆弱性管理及びリスクマネジメントの強化  
 担当: 細見さん