Merge pull request #405 from NorioKobota/revise-5.1

revise the phrases

Author: NorioKobota

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

@@ -373,18 +373,22 @@ For example, the two SBOMs below use different package names - one as 'hello' an
 Although verifying that these represent the same package is possible by comparing, for instance, their PURLs, the fact that different tools may write different values for the same key frequently leads to confusion and poses challenges to the smooth operation of SBOM management.  
 
 #### 5.1.3 Improvement Measures  
-- Establish and disseminate unified naming conventions based on industry standards or internal guidelines, including concrete examples (such as regular expression format examples).  
-- Deploy automated verification tools to assess whether package names, version numbers, and supplier details comply with the set standards.  
-- Set up periodic reviews and feedback loops among stakeholders to refine and update the naming guidelines.
+- Organizations involved in the software supply chain shall agree to document values - such as purl - that uniquely identify a package.  
+- A standardized notation rule based on industry standards or internal guidelines shall be formulated, and concrete examples (e.g., format examples using regular expressions) shall be widely shared among the organizations involved in the software supply chain.  
+- Verification tools shall be shared among the organizations in the software supply chain, and a mechanism shall be established to check whether the following items - crucial for package identification and prone to inconsistent notation—comply with the established rules:  
+  - Package name  
+  - Package version  
+  - Package supplier name  
+  - Package source  
+  - Presence of purl  
 
 #### 5.1.4 Evaluation Methods  
-- Quantitatively monitor rule violation counts (errors or deviations) using automated checkers before and after guideline implementation.  
-- Conduct random sampling of SBOM entries to manually verify adherence to the naming conventions.  
-- Gather qualitative feedback from internal users regarding improvements in consistency and clarity.
+- Randomly check whether each documented item adheres to the standardized notation rules, and evaluate the compliance rate.  
 
 #### 5.1.5 Risks and Considerations  
-- Automated tools might not capture all edge cases or exceptions in naming.  
-- Updates to naming guidelines may induce short-term confusion if not clearly communicated and documented.
+- If the documentation rules are inadequately defined or overly complex, there is a risk of misclassification due to incomplete handling of exceptional cases or unique notations.
+- If the rules deviate from actual operational practices, there is a risk of misclassification resulting from either insufficient or excessively stringent checks.
+- It should be noted that complete automation of tools and processes is challenging; therefore, final checks and exception handling will require manual review.  
 
 ### 5.2 Standardization and Normalization of Component Granularity
 

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

@@ -128,25 +128,37 @@
 #### 5.1 情報記述の正確性および一貫性の確保  
 
 ##### 5.1.1. 課題の概要  
-パッケージ名、バージョン、サプライヤー名などの記述について、各部署やツールごとに表記方法が異なるため、情報の正確性と一貫性が欠如しています。統一された基準がない場合、SBOMの自動解析や脆弱性マッチング等において、正確な判定が困難になる。
+異なる企業やツール間において、パッケージ名、バージョン、供給者名などの情報が一貫せず表現されるという課題が存在する。記述内容に関する統一された基準が欠如しているため、SBOMの自動解析や脆弱性との照合が困難となり、結果として正確な処理が妨げられる事態が生じる。  
 
 ##### 5.1.2. 課題の詳細  
-例えば、様々な仕様やガイドラインにおいて SBOM では パッケージ名の記載が必須となっているが、その記述内容については明確な規程が無い。その為、サプライヤーによっては、パッケージ名称にバージョン情報を含めたり、パッケージ名称にディストリビューション名が含まれている等、各部署やツールごとに表記方法が異なる。この場合、全く同じパッケージであっても、受領側で同一パッケージであることを特定することが困難になる。
+多くのSBOMガイドラインでは、記載すべき内容を示すキーが明示され、対応する値も定められているものの、これら値の具体的な書式が定義されていないケースが多く、実際の運用において問題が発生する可能性がある。  
+
+例えば、以下の2つのSBOMでは、パッケージ名の記載方法が異なっており、一方は「hello」、もう一方は「hello 0.0.1」となっている。この不一致は、使用されたツールの出力形式の違いに起因するものである。  
+
+- [example7-bin.spdx.json](https://github.com/spdx/spdx-examples/blob/master/software/example7/spdx2.2/example7-bin.spdx.json#L44)  
+  "name": "hello"  
+- [hello-dist.spdx.json](https://github.com/spdx/spdx-examples/blob/master/software/example12/spdx2.2/hello-dist.spdx.json#L56)  
+  "name": "hello 0.0.1"  
+
+これらが同一パッケージであることは、例えば ExternalRef や components の identifier として purl 等を用いて比較すれば確認可能ではあるが、各ツールが同一のキーに対して異なる値を出力するケースが多くみられるため、SBOM管理の円滑な運用に支障を来す恐れがある。  
 
 ##### 5.1.3. 改善策  
-- 業界標準や社内ルールに基づいた統一表記ルールを策定し、具体例（正規表現などのフォーマット例）を広く共有。  
-- 自動検証ツールを提供、各パッケージ名・バージョン・サプライヤー名の記載がルールに準拠しているかをチェックする仕組みを構築。  
-- 定期的なレビューおよびフィードバックプロセスを整備し、記載基準の変更や改善策の継続的なアップデートを実施。
+- purl など一意にパッケージを特定可能な値を記載することをソフトウェアサプライチェーン上関係する組織間で合意する。  
+- 業界標準や社内ルールに基づいた統一表記ルールを策定し、具体例（正規表現などのフォーマット例）をソフトウェアサプライチェーン上関係する組織間で広く共有する。  
+- 検証ツールをソフトウェアサプライチェーン関係組織間で共有、パッケージの特定に必要かつ表記が揺れがちな以下の項目について、ルールに準拠しているかをチェックする仕組みを構築する。  
+  - パッケージ名  
+  - パッケージバージョン  
+  - パッケージサプライヤー名  
+  - パッケージの取得元  
+  - purlの記載有無  
 
 ##### 5.1.4. 評価方法  
-- 自動検証ツールによるルール違反件数の定量的なモニタリングを実施し、改善前後の誤記や不整合件数の減少率を評価。  
-- 定期的に、各記述項目が統一ルールに沿って記載されているかをランダムにチェックし、合格率を評価。  
-- フィードバックプロセス内で、ツールやルールの更新による運用効果を各社各部門間などで共有し、改善効果の定性的評価を合わせて実施。
+- 各記述項目が統一表記ルールに沿って記載されているかをランダムにチェックし、合格率を評価する。  
 
 ##### 5.1.5. リスクと留意事項  
-- 自動検証ツールのルール設定が不十分な場合、例外ケースや特殊な記述に対する対応が不完全になる可能性がある。  
-- ルールの改定や正規表現の例示が現場実態と乖離している場合、過度な自動チェックによって正当な情報が誤検知されるリスクがある。  
-- ツールやプロセスは完全自動化が難しく、最終的な精査や例外事項の対応は人的レビューが必要となる点を留意する必要がある.
+- 記述ルールの設定が不十分であったり複雑な場合、例外ケースや特殊な記述への対応が不完全になり、誤判定するリスクがある。  
+- ルールが現場実態と乖離している場合、不足または過度なチェックが発生、誤判定するリスクがある。  
+- ツールやプロセスは完全な自動化が難しく、最終的なチェックや例外対応は人的レビューが必要となる点について留意する必要がある。  
 
 #### 5.2 コンポーネント粒度の標準化と正規化  
 担当: 田中さん