CVE Auditing With VEX #102
Conversation
Signed-off-by: naibu3 <[email protected]>
|
@HoussemNasri I would appreciate if you could also take a look here. |
|
|
||
| - **CSAF**, maintained by OASIS. Supports rich metadata, including product information, vulnerabilities, and remediation guidance. | ||
| - **CycloneDX**, is maintained by OWASP. Focuses on simplicity and interoperability. (Can be JSON or XML-based) | ||
| - **OpenVEX**, designed specifically for simplicity and ease of use. It is maintained by the OpenVEX community. |
There was a problem hiding this comment.
I strongly recommend CycloneDX, because as you said is maintained by OWASP.
I'd also suggest to check whether we could use a system like DependencyTracker (https://docs.dependencytrack.org/) to identify and reduce risk in the software supply chain.
|
|
||
| ### VEX Downloader | ||
|
|
||
| Retrieve VEX documents online. Is responsible finding, downloading and caching the files, like was done for OVAL [^2]. |
There was a problem hiding this comment.
I would add a line saying that the data will be processed in stream, to avoid any memory issues.3
|
|
||
| ##### Diagram | ||
|
|
||
|  |
There was a problem hiding this comment.
From your explanation and the db schema it's not clear to me how you plan on linking the VEX data to the package columns, so we know which package versions are affected by a CVE. For oval we have the suseOvalVulnerablePackage table. Do you plan to reuse it or use a similar one?
Your suseVEXProductVulnerablePackage table sounds like it would include such information, yet I don't see anything package related there.
VEX consumption in CVE audits
The aim of the project is to enhance CVE auditing accuracy using VEX profile.
Read rendered RFC.