chore(deps-dev): bump black from 24.4.2 to 24.8.0

dev-requirements.txt

@@ -1,4 +1,4 @@
-black==24.4.2
+black==24.8.0
 isort; python_version < "3.8"
 isort==5.13.2; python_version >= "3.8"
 pre-commit; python_version <= "3.8"

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.