Merge pull request #399 from no-ta/master

Modify description for 1 and 5.2

Author: NorioKobota

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

@@ -45,9 +45,14 @@ Key differences between the two documents include:
 
 ## 1. Scope
 
-This document “OpenChain SBOM Document Quality Guide” aims to outline certain requirements related to how an entity creates, delivers, and consumes Software Bill of Materials (SBOM), so that entities that produce and/or consume SBOMs that conform to this guide can ensure repeatability and streamlining of tools and processes for generating and consuming SBOMs. *Please Note* that this guide does not require a conforming entity to adopt OpenChain (in any version) but doing so is greatly encouraged.
+This document “OpenChain SBOM Document Quality Guide”is intended to form a common understanding among stakeholders in the supply chain. It presents improvements to improve the standardization, accuracy, transparency, and automation potential of SBOM.
 
-This guide is designed to work on a per SBOM level: an entity can use it as its sole way of delivering SBOMs but it is the individual SBOM that the guide refers to, not the entity that provides the SBOM. An SBOM using this guide can be called “OpenChain SBOM Document Quality Guide Compatible.”
+It helps to remove barriers in the distribution of software bills of materials (SBOM) by proposing improvements to common issues when the parties involved in the supply chain create, provide and use them.
+
+*Please Note* that this guide does not require a conforming entity to adopt OpenChain (in any version) but doing so is greatly encouraged.
+
+This guide is intended for all SBOM generation and operation target processes, including software packages, containers, SaaS, and embedded software. This guide refers to individual SBOMs, not the entities that provide them.
+An SBOM using this guide can be called “OpenChain SBOM Document Quality Guide Compatible.”
 
 Releasing SBOMs that match the requirements outlined in this guide does not preclude an entity from also delivering SBOMs for the same software in alternate ways or formats.
 

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

@@ -47,18 +47,18 @@
 
 担当: [田中の]
 
-本文書 "SBOM Quality Guide" は、サプライチェーンの中での関係者の共通理解を形成するためのドキュメントです。SBOMの標準化、正確性、透明性、及び自動化の可能性を高めるための改善策を提示します。
+本文書 "SBOM Document Quality Guide" は、サプライチェーンの中での関係者の共通理解を形成するためのドキュメントです。SBOMの標準化、正確性、透明性、及び自動化の可能性を高めるための改善策を提示します。
 
 サプライチェーンの関係者がソフトウェア部品表（SBOM：Software Bill of Materials）を作成・提供・利用する場合に共通課題となる点について改善策を提案することにより、SBOM流通時の障壁を取り除くための助けとなります。
 
-本ガイドは、本ガイドに適合するエンティティに対して、OpenChain （OpenChain Specificationのどのバージョンでも）を採用することを要求するものではありませんが、OpenChainを採用することが大いに推奨されることに留意ください。(Comment:この文必要?)
+本ガイドは、本ガイドに適合するエンティティに対して、OpenChain （OpenChain Specificationのどのバージョンでも）を採用することを要求するものではありませんが、OpenChainを採用することが大いに推奨されることに留意ください。
 
 このガイドは、ソフトウェアパッケージ、コンテナ、SaaS、組込みソフトウェアなど、あらゆるSBOM生成及び運用における対象プロセスに適応することを前提に記述されています。本ガイドが参照するのは個々のSBOMであり、SBOMを提供するエンティティではありません。
-本ガイドに沿ったSBOMを「SBOM Quality Guide Compatible」と呼ぶことができます。
+本ガイドに沿ったSBOMを「SBOM Document Quality Guide Compatible」と呼ぶことができます。
 
 本ガイドの要件に一致するSBOMをリリースすることは、同じソフトウェアのSBOMを別の方法または形式で配信することを妨げるものではありません。
 
-本ガイドは Creative Commons Attribution License 4.0 (CC-BY-4.0)の下にライセンスされています。(Comment:＞ライセンスはこれでいい?)
+本ガイドは Creative Commons Attribution License 4.0 (CC-BY-4.0)の下にライセンスされています。(Comment:ライセンスはこれでいい?)
 
 ### 2. 用語と定義  
 [OpenChain Telco SBOM Guide Version 1.1の 2.用語と定義](https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain-Telco-SBOM-Guide_JP.md#2-%E7%94%A8%E8%AA%9E%E3%81%A8%E5%AE%9A%E7%BE%A9) を継承する。  
@@ -175,13 +175,15 @@ SBOMを1つのファイルにマージして提供するか、複数のファイ
 |Vendorが提供するアプリAのSBOM|パッケージ|アプリAのパッケージからファイルを分解してファイル単位にする|パッケージ単位|
 
 上記の表からわかる通り、どのケースでも対応は可能だが、組み合わせによってMakerの作業の手間に違いが出ることが分かった。
-各SBOMのコンポーネントの粒度の違いにより異なる対応が必要になるということから、コンポーネントの粒度ががわからないと対応ができないということになる。
+各SBOMのコンポーネントの粒度の違いにより異なる対応が必要になるということから、コンポーネントの粒度ががわからないと対応が難しくなる。
 この例のように単純なサプライチェーンの場合は、SBOMに粒度の情報がなくても別の手段で確認することはできそうであるが、さらにサプライチェーンが複雑になるとSBOM自身に粒度の情報が必要となる。
 
 ##### 5.2.3. 改善策
 
-コンポーネントの粒度がわかるようになっていて、粒度に合わせた対応ができること。
-現実的には、SBOMの交換フォーマットの仕様によりパッケージとファイルの違いはわかるようになっているので問題ないと思われるが、フォーマットに関係なく上位レベルでコンポーネントの粒度の違がわかるようになっているという条件があることが必要だと考える。
+サプライチェーンの中で粒度が統一できるのであれば問題はない。
+統一できない場合は、コンポーネントの粒度がわかるようになっていて、粒度に合わせた対応ができないと問題になる可能性がある。
+SBOMの交換フォーマットの仕様によりパッケージとファイルの違いはわかるようになっているので現実的に問題になる状況は少ないと思われる。
+フォーマットの仕様に依存しない方法でコンポーネントの粒度の違いがわかるようになっていることが望ましいと考える。
 
 ##### 5.2.4. 評価方法