From f592d34d896a40f0afa1bafee5681a48a895a3da Mon Sep 17 00:00:00 2001 From: Terri Oda Date: Fri, 23 Aug 2024 12:03:15 -0700 Subject: [PATCH] docs: add info about supporting cpe in vex * fixes #4012 Signed-off-by: Terri Oda --- doc/triaging_process.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/triaging_process.md b/doc/triaging_process.md index e5021190a7..4c9fd4f07c 100644 --- a/doc/triaging_process.md +++ b/doc/triaging_process.md @@ -263,6 +263,12 @@ There are some limitations associated with product identification. We mainly use - Purl is used to identify products in the OpenVEX and CSAF formats. The format is `pkg:generic/{vendor}/{product}@{version}`. Here, the type is set to generic by default. However, if a language dependency file is being scanned and the CVE Binary Tool can generate a valid purl from processing it, the type is set to the respective dependency management type (e.g., go, pypi, gem, npm, etc.), and the namespace field is used for vendor information. +- As well as the identifiers above, cve-bin-tool can handle [CPE + identifiers](https://nvd.nist.gov/products/cpe) as used by NVD. These look like +`cpe:{cpe_version}:a:{vendor}:{product}:{version}` and can be useful in +ensuring that you get a specific set of records from NVD. We currently +support v2.2 and v2.3. + - Cve Binary Tool will also ignore the entries for components which are from VEX document but are not present in the file/binary being scanned and log a message asking weather the VEX document being scanned belongs to the file/binary being scanned, example: `Product: dio with Version: 1.3.2 not found in Parsed Data, is valid vex file being used?` This holy trio of vendor, product, and version/release allows the CVE Binary Tool to identify the component exactly and use it for the VEX process. Thus, it's no secret that the CVE Binary Tool works wonderfully with these. However, any VEX document generated outside the CVE Binary Tool may not be fully supported in the same way.