米国 CISA SBOM関連の二文書

こんにちは、丸山満彦です。

CISAがSBOMに関連する文書を「SBOMの種類」と「VEXの最小要件」の二つ出していますね。。。

⚫︎ CISA

ニュースリリース

・2023.04.21 CISA Releases Two SBOM Documents

CISA Releases Two SBOM Documents	CISAがSBOMの2つのドキュメントを公開
Today, CISA released two community-drafted documents around Software Bill of Materials (SBOM): Types of SBOM documents and Minimum Requirements for Vulnerability Exploitability eXchange (VEX).	本日、CISAはソフトウェア部品表（SBOM）に関する2つのコミュニティ起草文書を公開しました： 「SBOM文書の種類」と「脆弱性悪用可能性交換（VEX）の最小要件」である。
The Types of SBOM document summarizes common types of SBOMs that tools may create in the industry today, along with the data typically presented for each type of SBOM. As software goes from planning to source to build to deployed and used, tools may be able to detect subtle differences in the underlying components. These types will allow for better differentiation of tools and in the broader marketplace.	「SBOMの種類」は、今日、業界でツールが作成する可能性のある一般的なSBOMの種類と、各SBOMの種類に対して通常提示されるデータを要約している。ソフトウェアが計画からソース、ビルド、配備、使用へと進むにつれ、ツールは基礎となるコンポーネントの微妙な差異を検出できるようになるかもしれない。これらのタイプは、ツールおよび広範な市場でのより良い差別化を可能にする。
The Minimum Requirements for VEX document specifies the minimum elements to create a VEX document. This will allow interoperability between different implementations and data formats of VEX. It will also help promote integration of VEX into novel and existing security tools. This document also specifies some optional VEX elements.	「VEXの最小要件」文書では、VEX文書を作成するための最小限の要素を規定している。これにより、VEXの異なる実装やデータフォーマット間の相互運用性が可能になる。また、新規および既存のセキュリティ・ツールへのVEXの統合を促進するのに役立つ。また、この文書では、いくつかのオプションのVEX要素も規定している。
Led by CISA, both publications were debated and drafted by a community of industry and government experts with the goal to offer some common guidance and structure for the large and growing global SBOM community.	CISAが主導し、両出版物は、大きく成長する世界のSBOMコミュニティに共通の指針と構造を提供することを目的として、業界と政府の専門家のコミュニティによって議論され、起草された。

・2023.04.21 Types of Software Bill of Materials (SBOM)

Types of Software Bill of Materials (SBOM)	ソフトウェア部品表(SBOM)の種類
This document summarizes some common types of SBOMs that tools may create today, along with the data typically presented for each type of SBOM. It was drafted by a community-led working group on SBOM Tooling and Implementation, facilitated by CISA.	この文書は、今日ツールが作成する可能性のあるいくつかの一般的なタイプのSBOMと、各タイプのSBOMに通常提示されるデータをまとめたものである。この文書は、CISAが進行役を務めるSBOMツールおよび実装に関するコミュニティ主導のワーキンググループによって起草された。

・[PDF] 

Types of Software Bill of Material (SBOM) Documents	ソフトウェア部品表（SBOM）の種類
Introduction	はじめに
Today there is a widely used definition of the minimum content of a Software Bill of Material (SBOM).1 However, an SBOM may contain different forms of the minimum information sourced from different product artifacts. Given the disparate ways SBOM data can be collected, tool outputs may vary and provide value in different use cases. This document summarizes some common types of SBOMs that tools may create today, along with the data typically presented for each type of SBOM. An SBOM document may combine information for multiple SBOM types.	今日、ソフトウェア部品表（SBOM）の最小限の内容に関する広く使用されている定義がある1。しかし、SBOMには、異なる製品の成果物から得られた最小限の情報の異なる形式が含まれる場合がある。SBOMデータの収集方法が多様であるため、ツールの出力は異なるユースケースで価値を提供する可能性がある。この文書では、今日ツールが作成する可能性のあるいくつかの一般的なタイプのSBOMと、各タイプのSBOMに対して通常提示されるデータを要約する。SBOM文書では、複数のSBOMタイプに関する情報を組み合わせることができる。
Definitions and Discussions	定義と議論
The following two tables summarize the different types of SBOMs and the benefits and limitations of each type. This list of SBOM types is not intended to be tightly tied to the software lifecycle. Some SBOM types may be available and useful across multiple lifecycle phases, while others may be available only in one lifecycle phase. Also, the data presented within an SBOM type may vary, depending on the software’s lifecycle phase and industry.	次の2つの表は、SBOMのさまざまな種類と、それぞれの種類の利点と制限をまとめたものである。この SBOM タイプのリストは、ソフトウェアライフサイクルと緊密に関連付けることを意図してはいない。SBOMの種類によっては、複数のライフサイクルフェーズで利用可能で有用なものもあれば、あるライフサイクルフェーズでのみ利用可能なものもある。また、ソフトウェアのライフサイクルフェーズや業界によって、SBOMタイプで示されるデータは異なる場合がある。
Conclusion	結論
These definitions are meant as a starting point for clarifying SBOM types that varying tooling types and methods may create. Different tooling approaches may be required to create the same SBOM type for different kinds of software. This document may evolve as the innovation around SBOMs and their uses may require the addition of more SBOM types. Progress in adopting and refining Vulnerability Exploitability eXchange[1] (i.e., VEX), service dependencies, and “SBOM of SBOMs,” among others, may require additional types of SBOMs.	これらの定義は、さまざまなツールタイプおよび方法が作成する可能性のあるSBOMタイプを明確にするための出発点として意図されている。異なる種類のソフトウェアに対して同じ SBOM タイプを作成するために、異なるツールアプローチが必要となる場合がある。SBOMとその使用に関する技術革新により、より多くのSBOMタイプを追加する必要があるため、この文書は進化する可能性がある。脆弱性悪用可能性交換[1]（すなわちVEX）、サービス依存性、および「SBOMのSBOM」等の採用および改良の進展により、SBOMの追加タイプが必要となる可能性がある。
[1] See https://ntia.gov/files/ntia/publications/vex_one-page_summary.pdf for an initial overview. More information will be available at https://www.cisa.gov/sbom.

SBOMタイプ	定義	データ内容	メリット	制限事項
デザイン  Design	新しいソフトウェア成果物のために意図され、計画されたソフトウェアプロジェクトまたは製品に含まれるコンポーネント（一部はまだ存在しないかもしれない）のSBOM。	通常、設計仕様書、RFP、または初期コンセプトから派生する。	ライセンス購入や取得に先立ち、互換性のないコンポーネントを強調する。	非常に難しいかもしれない。
			開発者が使用する部品リストとして、承認または推奨する部品リストを定義している。	他のSBOMタイプに比べ、細部まで確認することができない。
ソース Source	製品アーティファクトを構築するために使用される開発環境、ソースファイル、および含まれる依存関係から直接作成されるSBOM。	通常、ソフトウェア構成分析（SCA）ツールから生成され、手動で明確化される。	ビルドプロセスにアクセスすることなく可視化できる。	実行されない、あるいは配備されたコードでコンパイルされないコンポーネント（脆弱性を持つ可能性がある）を強調するかもしれない。
			脆弱性をソースで修正することを容易にすることができる。	言語/エコシステムによっては、ランタイム、プラグイン、またはアプリケーションサーバーやプラットフォームライブラリのような動的コンポーネントを含まない場合がある。
			含まれるコンポーネントの依存関係ツリー/階層を表示することができる。	完全性のために他のSBOMへの参照を必要とする場合がある。
ビルド Build	ソースファイル、依存関係、ビルドされたコンポーネント、ビルドプロセスのエフェメラルデータ、および他のSBOMなどのデータから、リリース可能なアーティファクト（実行ファイルまたはパッケージなど）を作成するためにソフトウェアを構築するプロセスの一部として生成されたSBOM。	通常、ビルドプロセスの一部として生成される。最終的なリリース成果物SBOMのために、統合された中間ビルドおよびソースSBOMで構成されることがある。	ビルドやCI/CD（Continuous Integration/Continuous Deployment）プロセスで得られる情報により、製品アーティファクトのSBOM表現が正しいという信頼性が高まる。	このSBOMを生成するために、ビルドプロセスを変更する必要があるかもしれない。
			ソースコードだけでなく、より多くのコンポーネントを可視化することができる。	ビルドが実行されるビルド環境に大きく依存する。
			同じビルドワークフローで SBOM と製品アーティファクトの署名を可能にすることで、信頼性を向上させる。	間接的な依存関係や実行時の依存関係を把握することが困難な場合がある。
				動的にリンクされた依存関係（言語やエコシステムによって実行時に置き換わる可能性がある）の正しいバージョンを含んでいない可能性がある。
分析済み Analyzed	ビルド後のアーティファクト（実行ファイル、パッケージ、コンテナ、仮想マシンイメージなど）の解析を通じて生成されるSBOM。このような分析には、一般にさまざまなヒューリスティックが必要である。文脈によっては、これは「サードパーティ」SBOMとも呼ばれることがある。	通常、サードパーティツールによる成果物の分析を通じて生成される。	レガシーファームウェアの成果物のように、アクティブな開発環境がなくても可視化できる。	ソフトウェアコンポーネントを正確に分解・認識できないため、省略やエラー、近似値が発生する可能性がある。
			ビルドプロセスにアクセスする必要がない。	ヒューリスティックやコンテキスト固有のリスク要因に依存する可能性がある。
			他のソースからの SBOM データの検証を支援することができる。他のSBOMタイプ作成ツールで見落とされている隠れた依存関係を見つけることができる。
実装された Deplyed	システム上に存在するソフトウェアのインベントリーを提供するSBOM。これは、構成オプションの分析、および（潜在的にシミュレートされた）展開環境での実行動作の調査を組み合わせた、他のSBOMのアセンブリである可能性がある。	通常、システムにインストールされた成果物のSBOMと構成情報を記録することによって生成される。	システム上にインストールされたソフトウェアコンポーネント（アプリケーションを実行するために使用されるその他の設定やシステムコンポーネントを含む）を表示します。	インストールやデプロイのプロセスを変更する必要がある場合があります。
				アクセスできないコードにコンポーネントが存在する可能性があるため、ソフトウェアの実行環境を正確に反映できない可能性がある。
ランタイム (Runtime)	ソフトウェアを実行するシステムを計測して生成されたSBOM。システム内に存在するコンポーネントだけでなく、外部呼び出しまたは動的にロードされるコンポーネントも捕捉する。文脈によっては、これを「計装」または「動的」SBOMと呼ぶこともある。	通常、システムと相互作用するツールから、実行中の環境および/または実行されたアーティファクトを記録することによって生成される。	動的にロードされるコンポーネントや外部接続を含め、システム実行時に何が使用されているかを把握するための可視性を提供する。	実行中のシステムを解析する必要があるため、オーバーヘッドが発生する可能性がある。
			コンポーネントがアクティブかどうか、どの部分が使用されているかなどの詳細情報を含むことができる。	詳細な情報は、システムの全機能が使用されるまで一定期間実行された後でなければ得られない場合がある。

・2023.04.21 Minimum Requirements for Vulnerability Exploitability eXchange (VEX)

Minimum Requirements for Vulnerability Exploitability eXchange (VEX)	脆弱性悪用可能性交換(VEX)の最小要件
This document specifies the minimum elements to create a Vulnerability Exploitability eXchange (VEX) document. These elements are derived from, but may not fully conform to, existing VEX documentation and implementations. It was drafted and debated by experts from across the security and software world, representing different sectors and backgrounds.	この文書は、脆弱性悪用可能性交換（VEX）文書を作成するための最小限の要素について規定するものである。これらの要素は、既存のVEX文書や実装に由来するものであるが、完全に適合するものではない可能性がある。この文書は、セキュリティとソフトウェアの世界の様々な分野と背景を持つ専門家によって起草され、議論された。

・[PDF]