Skip to content

Commit e1d18f2

Browse files
authored
Merge pull request #412 from no-ta/master
Revise contents in 5.2
2 parents d197ba3 + a1dcb10 commit e1d18f2

1 file changed

Lines changed: 18 additions & 8 deletions

File tree

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

Lines changed: 18 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -183,28 +183,32 @@ SBOMを1つのファイルにマージして提供するか、複数のファイ
183183
|||MakerがUserに提供するSBOM|MakerがUserに提供するSBOM|
184184
|-|-|-|-|
185185
||コンポーネントの単位|ファイル|パッケージ|
186-
|Vendorが提供するアプリAのSBOM|ファイル|ファイル単位|アプリAが依存するOSSのファイル情報をパッケージ情報に変換してアプリAのみファイル単位にする|
187-
|Vendorが提供するアプリAのSBOM|パッケージ|アプリAのパッケージからファイルを分解してファイル単位にする|パッケージ単位|
186+
|Vendorが提供するアプリAのSBOM|ファイル|ファイル単位|MakerがアプリAから依存があるOSSのファイル情報をパッケージ情報に変換してアプリAのみファイル単位にする|
187+
|Vendorが提供するアプリAのSBOM|パッケージ|MakerがアプリAのパッケージからファイルを分解してファイル単位にする|パッケージ単位|
188188

189189
上記の表からわかる通り、どのケースでも対応は可能だが、組み合わせによってMakerの作業の手間に違いが出ることが分かった。
190-
各SBOMのコンポーネントの粒度の違いにより異なる対応が必要になるということから、コンポーネントの粒度ががわからないと対応が難しくなる。
190+
ただし、実際に必要となる作業については使用するツールによって状況が変わる可能性があるので、必ずしも上記で述べた対応が必要になるとは限らない。
191+
しかし、各SBOMのコンポーネントの粒度の違いにより異なる対応が必要になるということは明らかである。
192+
その場合、コンポーネントの粒度がわからないと対応が難しくなる。
191193
この例のように単純なサプライチェーンの場合は、SBOMに粒度の情報がなくても別の手段で確認することはできそうであるが、さらにサプライチェーンが複雑になるとSBOM自身に粒度の情報が必要となる。
192194

195+
193196
##### 5.2.3. 改善策
194197

195198
サプライチェーンの中で粒度が統一できるのであれば問題はない。
196-
統一できない場合は、コンポーネントの粒度がわかるようになっていて、粒度に合わせた対応ができないと問題になる可能性がある
197-
SBOMの交換フォーマットの仕様によりパッケージとファイルの違いはわかるようになっているので現実的に問題になる状況は少ないと思われる
198-
フォーマットの仕様に依存しない方法でコンポーネントの粒度の違いがわかるようになっていることが望ましいと考える
199+
統一できているかわからない場合は、コンポーネントの粒度がわかるようになっている上で、粒度に合わせた対応を行うことが必要になる
200+
実際には、SBOMの交換フォーマットの仕様によりパッケージとファイルの違いはわかるようになっているので問題になる状況は少ないと思われる
201+
とはいえ、フォーマットの仕様に依存することなく、コンポーネントの粒度の違いを表現できるようなSBOMの仕様になっていることが望ましいと考えられる
199202

200203
##### 5.2.4. 評価方法
201204

202205
最終商品のSBOMを作成するために外部から受け取ったり、内部で作成したりした複数のSBOMについてこの粒度の違いがあるのかを判別できること。
206+
さらに、粒度の違いに合わせた対応ができるかどうかがわかること。
203207

204208
##### 5.2.5. リスクと留意事項
205209

206-
コンポーネントの粒度の違いをSBOMの表記上では解決できたとしても、実際に脆弱性情報と紐づけるときに問題が起きるのではないか
207-
例えば、コンポーネントの粒度がファイル単位の情報が混ざっている場合に、脆弱性情報とのマッピングが手間なくできるのかという懸念がある
210+
コンポーネントの粒度の違いをSBOMの表記上では解決できたとしても、実際に脆弱性情報と紐づけるときに問題が起きるのではないかという懸念がある
211+
例えば、コンポーネントの粒度にファイル単位の情報が混ざっている場合に、依存関係をたどる中で脆弱性情報とのマッピングに手間がかかるようになると考えられる
208212

209213

210214
#### 5.3 ソース情報の補完と透明性向上
@@ -659,6 +663,12 @@ SPDX 及び CycloneDX の仕様に詳しい人々にレビューをしてもら
659663
660664
- SPDX 2.3
661665

666+
|||MakerがUserに提供するSBOM|MakerがUserに提供するSBOM|
667+
|-|-|-|-|
668+
||コンポーネントの単位|[ファイル](./example5.2/component-granularity-productX-maker-file-spdx23.json)|[パッケージ](./example5.2/component-granularity-productX-maker-package-spdx23.json)|
669+
|Vendorが提供するアプリAのSBOM|[ファイル](./example5.2/component-granularity-appA-vendor-file-spdx23.json)|ファイル単位|[MakerがアプリAから依存があるOSSのファイル情報をパッケージ情報に変換してアプリAのみファイル単位にする](./example5.2/component-granularity-productX-user-file-spdx23.json)|
670+
|Vendorが提供するアプリAのSBOM|[パッケージ](./example5.2/component-granularity-appA-vendor-package-spdx23.json)|[MakerがアプリAのパッケージからファイルを分解してファイル単位にする](./example5.2/component-granularity-productX-user-package-spdx23.json)|パッケージ単位|
671+
662672
- SPDX 3.0.1
663673

664674
- CycloneDX 1.6

0 commit comments

Comments
 (0)