米国 CISA 脆弱性悪用可能性交換情報の発行時期

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

VEX (脆弱性悪用可能性交換情報）の発行時期に関する文書がCISAから公開されていますね。。。

● CISA

・2023.11.06 When to Issue VEX Information 

CISA Published When to Issue VEX Information	CISA、VEX情報の発行時期を発表
Today, CISA published When to Issue Vulnerability Exploitability eXchange (VEX) Information, developed by a community of industry and government experts with the goal to offer some guidance and structure for the software security world, including the large and growing global SBOM community.	本日、CISAは「脆弱性悪用可能性交換（VEX）情報の発行時期（When to Issue Vulnerability Exploitability eXchange (VEX) Information）」を公表した。これは、業界と政府の専門家からなるコミュニティが、大きく成長しつつある世界的なSBOMコミュニティを含むソフトウェアセキュリティの世界に何らかの指針と仕組みを提供することを目的として開発したものである。
This guide explains the circumstances and events that could lead an entity to issue VEX information and describes the entities that create or consume VEX information. Whether, and when, to issue VEX information is a business decision for most suppliers and possibly a more individual decision for independent open source developers. This document identifies factors that influence the decision.	このガイドでは、事業体がVEX情報を発行する可能性のある状況や事象について説明し、VEX情報を作成または消費する事業体について記述する。VEX 情報を発行するかどうか、またいつ発行するかは、ほとんどの供給者にとってはビジネス上の決定であり、おそらく独立したオープンソース開発者にとってはより個人的な決定である。この文書では、その決定に影響を与える要因を特定する。
For more information, read the new reference material When to Issue Vulnerability Exploitability eXchange (VEX) Information.	詳細については、新しい参考資料「脆弱性悪用可能性交換（When to Issue Vulnerability Exploitability eXchange: VEX）情報」を参照のこと。

・2023.11.06 When to Issue VEX Information

・[PDF] When to Issue VEX Information

When to Issue VEX Information	VEX情報の発行時期
Introduction	序文
“The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other parties to assert the exploitability status of specific vulnerabilities in a particular product or set of products.”  Issuing VEX information allows developers, suppliers, and others to provide information in a human-readable and machine-comprehensible format, regardless of whether or not software is affected by a specific vulnerability. This allows downstream users to make their own assessments of the risks associated with the vulnerability.	脆弱性悪用可能性交換（VEX）の目的は、ソフトウェア供給者などが、特定の製品または製品群における特定の脆弱性の悪用可能性を主張できるようにすることである。  VEX情報を発行することで、ソフトウェアが特定の脆弱性の影響を受けるかどうかにかかわらず、開発者、供給者、その他の関係者が、人間が読め、機械が理解できる形式で情報を提供できるようになる。これにより、下流のユーザーは、脆弱性に関連するリスクを独自にアセスメントすることができる。
This document seeks to explain the circumstances and events that could lead an entity to issue VEX information and describes the entities that create or consume VEX information. Whether, and when, to issue VEX information is a business decision for most suppliers and possibly a more individual decision for independent open source developers. This document identifies factors that influence the decision.	本文書は、事業体がVEX情報を発行することになる状況や事象を説明し、VEX情報を作成または消費する事業体について説明することを目的とする。VEX 情報を発行するかどうか、いつ発行するかは、ほとんどの供給者にとってはビジネス上の決定事項であり、 独立したオープンソース開発者にとっては、おそらくより個人的な決定事項である。本文書は、その決定に影響を与える要因を特定する。
For background information on VEX, including definitions of VEX data elements and other terminology used in this document, see Minimum Requirements for Vulnerability Exploitability eXchange (VEX),[1] Vulnerability Exploitability eXchange (VEX) - Status Justifications,[2] and Vulnerability Exploitability eXchange (VEX) - Use Cases.[3]	脆弱性悪用可能性交換（VEX）の最低要件[1]、脆弱性悪用可能性交換（VEX） - 状況の正当性[2]、および脆弱性悪用可能性交換（VEX） - 使用事例[3]を参照のこと。
Who issues VEX information	誰が VEX 情報を発行するか
Various roles may issue VEX information. This section offers some common examples, but it is not meant to be an exhaustive or limiting set.	さまざまな役割が VEX 情報を発行する可能性がある。このセクションでは、一般的な例をいくつか示すが、網羅的または限定的なセットであることを意図するものではない。
Supplier	供給者
A supplier is an entity that provides a particular product, software package, library, or component. A supplier could be the original developer of the software, a downstream commercial user, or a third party that repackages the software as a component or dependency of another product. Examples of suppliers include individual software developers, commercial software or device producers, and Linux distributions. Suppliers can issue VEX information to inform their users or customers about the status of a vulnerability in a given product.	供給者とは、特定の製品、ソフトウェアパッケージ、ライブラリ、コンポーネントをプロバイダと して提供する事業体である。供給者は、そのソフトウエアの最初の開発者、下流の商用ユーザ、またはそのソフトウエアを他の製品のコンポーネントや依存要素として再パッケージ化するサードパーティである。供給者の例としては、個々のソフトウェア開発者、商用ソフトウェアやデバイスの製造者、Linuxディストリビューションなどがある。供給者は、ある製品の脆弱性の状況をユーザや顧客に知らせるために、VEX情報を発行することができる。
Open-source software	オープンソースソフトウェア
In the context of open source software, active developers, maintainers, or project members are examples of suppliers who could provide VEX information. If such roles do not exist, downstream users or community members could provide VEX information. Unmaintained software carries a variety of security and development risks beyond the availability of VEX information.	オープンソースソフトウェアの文脈では、活動的な開発者、メンテナ、またはプロジェクトメンバが、VEX情報を提供できる供給者の例である。そのような役割が存在しない場合、下流のユーザやコミュニティメンバが VEX 情報を提供する可能性がある。保守されていないソフトウェアには、VEX 情報の利用可能性以外にも、様々なセキュリティリスクや開発リスクがある。
Researcher	研究者
A researcher or finder is an individual or organization that conducts security research or similar assessments and discovers potential vulnerabilities. Examples of this would be individual security researchers or academics, professional bug bounty hunters, or commercial security companies. Researchers could use VEX to report vulnerabilities to suppliers or to publish the status of their findings. Depending on the researcher’s visibility and access to the software, their VEX information may be different than VEX information from suppliers.	研究者または発見者は、セキュリティ研究または類似の評価を実施し、潜在的な脆弱性を発見する個人または組織である。この例としては、個人のセキュリティ研究者や学者、プロのバグ報奨金ハンター、あるいは商業的なセキュリティ会社が挙げられる。研究者は、脆弱性を供給者に報告したり、発見した状況の公表のために VEX を利用することができる。ソフトウエアに対する研究者の可視性とアクセス権によっては、研究者の VEX 情報は、供給者の VEX 情報とは異なるかもしれない。
Vulnerability coordinator	脆弱性コーディネーター
A vulnerability coordinator is not directly involved in the production of software and assists suppliers, researchers, and others to disclose vulnerabilities in a way that minimizes overall risk. Examples include publicly funded teams like CISA and JPCERT/CC. Commercial bug bounty platforms can also act as coordinators. Coordinators could issue VEX information to provide the status of cases they coordinate. Depending on the coordinator’s visibility and access to the software, their VEX information may be different than VEX information from suppliers.	脆弱性コーディネータは、ソフトウェアの製造には直接関与せず、供給者、研究者、その他の者が全体的なリスクを最小化する方法で脆弱性を開示するのを支援する。例としては、CISA や JPCERT/CC のような公的資金で運営されているチームがある。商用のバグ報奨金プラットフォームもコーディネータとして機能することができる。コーディネータは、VEX 情報を発行して、コーディネートするケースの状況を提供することができる。コーディネーターの可視性とソフトウエアへのアクセスに よって、コーディネーターのVEX情報は、供給者からのVEX情報とは異なる可能性がある。
Vulnerability detection and management	脆弱性の検知と管理
Vulnerability detection and management tools are designed to detect, manage, and report on vulnerabilities. Examples include proprietary or open source vulnerability scanners, software composition analysis (SCA), binary analysis, Application Security Posture Management (ASPM), penetration testing, and security information and event management (SIEM) systems. Such tools may consume or produce VEX information. To reduce false positives, these tools should sufficiently validate the accuracy of VEX information, involving human analysts when necessary.	脆弱性検知・管理ツールは、脆弱性を検知し、管理し、報告するように設計されている。例えば、プロプライエタリまたはオープンソースの脆弱性スキャナ、ソフトウェア構成分析（SCA）、バイナリ分析、アプリケーションセキュリティポスチャ管理（ASPM）、侵入テスト、セキュリティ情報・イベント管理（SIEM）システムなどがある。このようなツールは、VEX情報を消費または生成する可能性がある。誤検知を減らすために、これらのツールは、VEX 情報の正確性を十分に検証し、必要な場合は人間の分析者が関与すべきである。
Other parties	その他の関係者
Other parties that may issue VEX information include any entity that might assume responsibility for testing the security of particular software. Examples include regulators, reviewers, service providers, sophisticated software users, auditors, software and technology distributors, and contract software support organizations.	VEX 情報を発行する可能性のあるその他の関係者には、特定のソフトウエアのセキュリ ティをテストする責任を負う可能性のある事業体が含まれる。例えば、規制当局、レビュワー、サービスプロバイダー、高度なソフトウエアユーザー、監査人、ソフトウエア及び技術の販売業者、ソフトウエアのサポート業務を請け負う組織などである。
When VEX information could be issued	VEX情報の発行時期
Various events can drive the issuance of VEX information. The decisions and timing around providing VEX information are primarily business decisions and are not determined by a strict protocol. Common examples are described in this section. These examples are not intended to be comprehensive and are not organized in any specific way. These examples do not limit the events or time frames that can influence the issuance of VEX information.	VEX情報の発行は、様々な出来事によって推進される可能性がある。VEX情報の提供に関する決定とタイミングは、主としてビジネス上の決定であり、厳密な手順によって決定されるものではない。よくある例をこのセクションで説明する。これらの例は包括的であることを意図しておらず、特定の方法で整理されているわけでもない。これらの例は、VEX情報の発行に影響を及ぼしうる事象や時間枠を限定するものではない。
Upstream vulnerability discovered	上流で脆弱性が発見される
As new vulnerabilities are discovered and disclosed, it is common for users or customers to ask for status updates. Issuing VEX information allows users, customers, and the public (if desired) to see the current status and should reduce the number of questions about the vulnerability.	新たな脆弱性が発見され公表されると、ユーザーや顧客から状況の更新を求められるのが一般的である。VEX情報を発行することで、ユーザ、顧客、および（必要であれば）一般の人々が現在の状況を確認することができ、脆弱性に関する質問の数を減らすことができるはずである。
In the course of vulnerability management or other security monitoring activities, a supplier becomes aware of a newly discovered vulnerability that affects an upstream component used by one or more of the supplier’s products. While many upstream component vulnerabilities are not exploitable in downstream products, it is natural to assume that the presence of the vulnerable software or component implies risk, especially when the vulnerability is in a known component listed in a software bill of materials (SBOM).	脆弱性管理又は他のセキュリティ監視活動の過程で、供給者は、供給者の一つ又はそれ以上の製品で使用されている上流コンポーネントに影響する脆弱性が新たに発見されたことに気づく。上流コンポーネントの脆弱性の多くは下流製品では悪用できないが、脆弱性のあるソフトウェアやコンポーネントの存在はリスクを意味すると考えるのは自然なことである。
When this happens, users will attempt to determine to what extent they are affected by the vulnerability. It is common for users to contact the supplier directly, placing a burden on the supplier’s communications, support, and cybersecurity teams. By issuing VEX information, the supplier can reduce support calls and communications for incident response teams. As the supplier refines its understanding of the vulnerability, the supplier should update or issue additional VEX information. A vulnerability response program using VEX should provide uniform, up to date, and timely information to help users and suppliers manage their cybersecurity response.	このような場合、ユーザーは、自分たちが脆弱性の影響をどの程度受けるかを判断しようとする。ユーザが供給者に直接連絡するのが一般的であり、供給者のコミュニケーション、サポート、サイバーセキュリティチームに負担がかかる。VEX 情報を発行することで、供給者はサポートへの問い合わせやインシデント対応チー ムのコミュニケーションを減らすことができる。供給者が脆弱性の理解を深めるにつれて、供給者は追加の VEX 情報を更新または発行すべきである。VEX を使用する脆弱性対応プログラムは、ユーザと供給者がサイバーセキュリティ対応を管理するのに役立 つ、統一された最新かつタイムリーな情報を提供すべきである。
Significant public attention	大きな社会的注目
When a vulnerability is “in the news” (see Figure 1Figure 1) and receiving significant public attention—often in the case of “zero-day,” other surprising public disclosure, or reports of active exploitation—it is imperative to provide status and mitigation information using VEX. Users, customers, and the public can access VEX information to obtain the latest vulnerability and exploitability information about the newly disclosed vulnerability. Even when suppliers are also surprised by the disclosure, they can use VEX to convey status information, including an initial “under_investigation.” Other parties can also issue VEX information. For example, a researcher or analyst could confirm exploitability for certain products or components.	脆弱性が「ニュースになり」（図 1 図 1 を参照）、社会的に大きく注目されている場合（多くの場合、「ゼロデイ」、その他の驚くような一般公開、または活発な悪用の報告の場合）には、VEX を使用してステータスと低減情報を提供することが不可欠である。ユーザ、顧客、および一般市民は、VEX の情報にアクセスすることで、新たに公開された脆弱性に関する最新の脆弱性と悪用可能性に関する情報を入手することができる。供給者もまた開示に驚いている場合でも、VEXを使用して、最初の "under_investigation "を含むステータス情報を伝えることができる。他の関係者もVEX情報を発行することができる。例えば、研究者やアナリストは、特定の製品やコンポーネントについて悪用可能性を確認することができる。
Figure 1: Timeline of named vulnerabilities	図 1: 名前が付けられた脆弱性のタイムライン
Active exploitation	積極的な悪用
When determining what vulnerabilities can have the most significant impact on the software supply chain, organizations should prioritize vulnerabilities causing immediate harm based on current adversarial activity. VEX “affected” status means that a vulnerability is exploitable, subject to a variety of circumstances. VEX does not specifically describe threat or the degree to which a vulnerability is being exploited, however, such information could be included in the “action_statement” field. Timeliness of notification when considering actively exploited vulnerabilities is vital. This will ensure organizations that consume the software product or component in question are equipped with the necessary information to limit their likelihood of compromise during the time in which the product or underlying components are actively targeted by malicious actors.	ソフトウェア・サプライチェーンに最も重大な影響を及ぼす脆弱性を決定する場合、組織は、現在の敵対的な活動に基づいて、直接的な被害をもたらす脆弱性に優先順位を付けるべきである。VEX の「影響を受ける（affected）」ステータスは、脆弱性が悪用可能であることを意味する。VEX では、脆弱性の脅威や脆弱性が悪用されている度合いを具体的に記述していないが、「action_statement」 フィールドにそのような情報を含めることは可能である。積極的に悪用される脆弱性を考慮する場合、通知の適時性は極めて重要である。これにより、当該ソフトウェア製品またはコンポーネントを利用する組織は、当該製品またはその基礎となるコンポーネントが悪意のある行為者に積極的に狙われている間、侵害の可能性を抑えるために必要な情報を確実に入手することができる。
There are a variety of public and proprietary sources that organizations may use to determine what known vulnerabilities are being actively exploited in the wild. For example, CISA maintains a publicly available database of exploited vulnerabilities in the Known Exploited Vulnerability (KEV) catalog.[4]	どのような既知の脆弱性が積極的に悪用されているかを判断するために、組織が利用できるさまざまな公開情報源や専有情報源がある。例えば、CISA は、Known Exploited Vulnerability（KEV）カタログにおいて、悪用された脆弱性の公開データベースを維持している[4]。
Status changes	状況の変化
In general, VEX issuers are expected to communicate any changes in status. Ideally, when a new vulnerability is disclosed, an “under_investigation” status should be issued. When the investigation has concluded, status should be updated, for example, noting that the product is “affected” or “not_affected.”	一般に、VEX の発行者は、ステータスに変更があれば、それをコミュニケーションすることが期待される。理想的には、新たな脆弱性が公表された場合、「調査中」のステータスが発行されるべきである。調査が終了したら、ステータスを更新し、例えばその製品が "affected" あるいは "not_affected" であることを示すべきである。
VEX information includes timestamps to indicate when the information was first issued and most recently updated. By updating a timestamp but not changing status or other information, a VEX issuer can reaffirm that the current status remains accurate at the present time.	VEXの情報には、その情報が最初に発行され、直近で更新された時期を示すタイムスタンプが含まれる。タイムスタンプは更新するが、ステータスやその他の情報は変更しないことで、 VEX発行者は、現在のステータスが現時点でも正確であることを再確認できる。
In addition to changes in vulnerability status, VEX can also convey changes to remediation actions (“action_statement”) and further details about “not_affected” status (“impact_statement”).	脆弱性ステータスの変更に加えて、VEXは改善措置の変更（「action_statement」）や「not_affected」ステータスの詳細（「impact_statement」）も伝えることができる。
Coordinated vulnerability disclosure	調整された脆弱性の開示
Coordinated vulnerability disclosure (CVD) and VEX are independent concepts and VEX is neither required by CVD nor does VEX affect CVD. VEX can be used during CVD whenever parties want to convey vulnerability status. For example, a researcher can use VEX as part of a private vulnerability report to a supplier or a supplier can use VEX to privately inform other suppliers. As covered elsewhere, VEX can be used in published vulnerability advisories.	調整された脆弱性の開示（CVD）とVEXは独立した概念であり、VEXはCVDに要求されるものでも、VEXがCVDに影響するものでもない。VEXは、当事者が脆弱性の状態を伝えたいときはいつでも、CVD中に使用することができる。例えば、研究者が供給者にプライベートな脆弱性報告の一部としてVEXを使用したり、供給者が他の供給者にプライベートな情報を伝えるためにVEXを使用したりすることができる。また、VEXは公表された脆弱性アドバイザリにも使用できる。
Legal requirements	法的要件
There may be legal requirements that create an obligation to issue VEX information. Contract terms could require that a supplier provides VEX information. Industries or sectors could develop guidance about using VEX. Governments could require the use of VEX, for example, in safety-regulated sectors.	VEX情報を発行する義務を生じさせる法的要件があるかもしれない。契約条項により、供給者がVEX情報を提供することを義務付けることができる。業界や部門がVEXの使用に関する指針を策定することができる。ガバナンスは、例えば安全規制部門においてVEXの使用を義務付けることができる。
Discussion	議論
While not strictly required for decisions to issue VEX information, the following sections provide additional guidance that may be important in deciding when to issue VEX information.	VEX情報を発行する決定には厳密には必要ではないが、以下のセクションは、VEX情報をいつ発行するかを決定する際に重要となりうる追加ガイダンスを提供する。
Tools and automation	ツールと自動化
To work well at scale, VEX will require automation and tools that support the ecosystem. In general, such tools can be grouped into the following three functional categories:	VEXを規模に応じてうまく機能させるためには、エコシステムをサポートする自動化とツールが必要となる。一般的に、そのようなツールは以下の3つの機能カテゴリーに分類することができる：
1. Tools that support the creation and maintenance of VEX information	1. VEX情報の作成と保守をサポートするツール
2. Tools that support the consumption of VEX information, also including automated response tools	2. VEX情報の消費をサポートするツール（自動応答ツールも含む
3. Tools that provide distribution or retrieval methods for VEX information	3. VEX情報の配布または検索方法をプロバイダするツール。
Different VEX implementations provide these functions within their ecosystem. Interoperability will be important as VEX concepts and implementations develop to support automation and VEX users choose the most appropriate tools for their ecosystems.	さまざまなVEX実装が、それぞれのエコシステム内でこれらの機能をプロバイダしている。VEXのコンセプトと実装が自動化をサポートするように発展し、VEXユーザーがそれぞれのエコシステムに最も適したツールを選択するようになれば、相互運用性が重要になる。
In general, the cost of tool creation, communication, and consumption can be reduced dramatically through automation. Nevertheless, some parts, e.g., the analysis of whether the product is affected, might still need human interaction and will therefore be hard to automate. Also, the unique identification of products and correlation against existing inventories are difficult problems to solve at scale, as long as there is a lack of consensus around a global software identification system.	一般的に、ツールの作成、コミュニケーション、消費にかかるコストは、自動化によって劇的に削減できる。とはいえ、いくつかの部分、例えば製品が影響を受けるかどうかの分析には、まだ人間との対話が必要な場合があり、自動化は難しいだろう。また、製品の一意な識別と既存の在庫との相関は、グローバルなソフトウェア識別システムに関するコンセンサスがない限り、大規模に解決するのは難しい問題である。
Software supply chain considerations	ソフトウェア・サプライチェーンの考慮事項
Supply chains and dependency relationships influence when to issue and how to use VEX information. Status inheritance	サプライチェーンと依存関係は、VEX 情報をいつ発行し、どのように使用するかに影響する。ステータスの継承
VEX information conveys data to VEX consumers who are often developers or suppliers. As a warning, VEX consumers should carefully evaluate if it is valid to inherit status from upstream components. Strictly speaking, consumers should not assume the status of an upstream component applies to a product that uses the component. Each component or product throughout a supply chain may require an independent VEX evaluation.	VEX情報は、多くの場合開発者や供給者であるVEXコンシューマーにデータを伝える。警告として、VEXコンシューマは、上流のコンポーネントからステータスを継承することが妥当かどうかを注意深く評価すべきである。厳密に言えば、コンシューマは、上流コンポーネントのステータスが、そのコンポーネントを使用する製品に適用されると仮定すべきではない。サプライチェーン全体を通して、各コンポーネントまたは製品ごとに、独立したVEX評価が必要となる場合がある。
In certain cases, and with due consideration, a VEX consumer may assume the VEX status of an upstream component can be inherited downstream. For example, a VEX status of “not_affected” with justification “component_not_present” or “vulnerable_code_not_present” could be inherited downstream, unless the vulnerable code is re-introduced elsewhere downstream.	場合によっては、十分な配慮のもと、VEXの消費者は、上流部品のVEXステータスが下流に継承 されると仮定してもよい。例えば、「component_not_present」又は「vulnerable_code_not_present」の正当性を伴う「not_affected」の VEX ステータスは、脆弱性コードが下流の別の場所に再導入されない限り、下流に継承される可能性がある。
Multiple supply chain paths	複数のサプライチェーンパス
VEX consumers should evaluate all supply chain paths and deconflict VEX information for multiple occurrences of the same upstream component. For example, the same upstream component may be used by multiple intermediate components and appear in multiple supply chain paths. To comprehensively evaluate supply chain paths, all VEX information needs to be provided and collected. Accurate SBOM information is important in understanding supply chain paths. VEX authors should consider how best to provide up to date VEX information to VEX consumers.	VEX コンシューマは、すべてのサプライチェーンパスを評価し、同じ上流コンポーネントが複数存在する場 合、VEX 情報の矛盾を解消すべきである。例えば、同じ上流コンポーネントが複数の中間コンポーネントによって使用され、複数のサプライチェーンパスに現れることがある。サプライチェーンパスを包括的に評価するためには、全てのVEX情報をプロバイダが提供し、収集する必要がある。正確な SBOM 情報は、サプライチェーンパスを理解する上で重要である。VEX認可者は、VEX消費者に最新のVEX情報を提供する最善の方法を検討すべきである。
Trust in VEX information	VEX情報の信頼性
VEX conveys assertions from the author. The downstream consumer of this information chooses the level of trust and confidence to place in this information. VEX information itself does not convey trust between VEX authors and consumers. Digitally signing VEX information is recommended to support trust in the origin and integrity of the information. Authors and consumers have different types of trust relationships and varying requirements to understand the pedigree and provenance of VEX information. VEX consumers may choose to apply additional validation of VEX information and authors, based on the consumer’s regulatory, compliance, or risk management obligations.	VEXは認可者の主張を伝えるものである。この情報の川下の消費者は、この情報にどの程度の信頼と確信を置くかを選択する。VEX情報そのものは、VEX作成者とVEX消費者の間の信頼を伝えるものではない。情報の出所と完全性に対する信頼を裏付けるために、VEX情報にデジタル署名を付けることが推奨される。認可者と消費者は、異なるタイプの信頼関係を持ち、VEX情報の血統と出所を理解するための要件も様々である。VEX コンシューマは、コンシューマの規制、コンプラ イアンス、またはリスクマネジメントの義務に基づき、VEX 情報および著者について追加的な検証を 適用することを選択することができる。
It is common and reasonable to treat VEX information from a supplier as authoritative for components and products produced or maintained by that supplier. VEX, however, does not dictate this or any trust policy. VEX includes authorship (the “author” field) and VEX consumers are free to determine their trust in sources of VEX information.	供給者が製造または保守する部品および製品については、供給者からのVEX情報を権威あるものとして扱うことが一般的かつ合理的である。ただし、VEXはこれまたはいかなる信頼方針も指示しない。VEXには認可（"author "フィールド）が含まれており、VEXの消費者はVEXの情報源に対する信頼を自由に決定することができる。
Open-source software	オープンソースソフトウェア
Regarding VEX, both open source and proprietary software components should operate similarly. For downstream consumers and suppliers of open source components, there are nuances around how upstream open source communities manage vulnerabilities.	VEXに関しては、オープンソースソフトウェアもプロプライエタリなソフトウェアコンポーネントも、同様に運用されるべきである。オープンソースコンポーネントの下流の消費者と供給者にとっては、上流のオープンソースコミュニティが脆弱性をどのように管理するかについて、微妙な違いがある。
For the purposes of VEX and the scope of this document, there are no meaningful differences between open source and proprietary software. Open source components are widely used in proprietary software products and open source suppliers can and should issue VEX information. Open source components can be used in different ways and independent VEX information should be issued for each use of any upstream component. However, it is important to acknowledge that many open source projects and maintainers do not have the resources to create and update VEX information. Similar to proprietary software, no user of open source software should assume that the absence of VEX, or other vulnerability information, implies a lack of risk.	VEXの目的と本文書の範囲では、オープンソースとプロプライエタリ・ソフトウェアの間に意味のある違いはない。オープンソース・コンポーネントは、プロプライエタリ・ソフトウェア製品に広く使用されており、 オープンソース・供給者は、VEX情報を発行することができ、また発行すべきである。オープンソースコンポーネントは、様々な方法で使用することができ、アップストリームコン ポーネントの使用ごとに、独立したVEX情報を発行すべきである。しかし、多くのオープンソースプロジェクトやメンテナには、VEX情報を作成・更新するリソースがないことを認識することが重要である。プロプライエタリ・ソフトウェアと同様に、オープンソースソフトウェアの利用者は、VEXやその他の脆弱性情報がないことを、リスクがないことを意味すると考えるべきではない。

[1] CISA. Minimum Requirements for Vulnerability Exploitability eXchange (VEX). Apri 21, 2023. https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability- exchange-vex.

[2] CISA. Vulnerability Exploitability eXchange (VEX) Status Justification Document. June 1, 2022. https://www.cisa.gov/resources-tools/resources/vulnerability-exploitability-exchange- vex-status-justification-document-june-2022.

[3] CISA. Vulnerability Exploitability eXchange (VEX) Use Case Document. April 1, 2022. https://www.cisa.gov/resources-tools/resources/vulnerability-exploitability-exchange-vex-use-case- document-april-2022.

[4] CISA. Known Exploited Vulnerabilities Catalogue. October 10, 2023. https://www.cisa.gov/known-exploitedvulnerabilities-catalog