feat(vex): CSAF support #1826
feat(vex): CSAF support #1826
Conversation
Signed-off-by: juan131 <[email protected]>
|
Still a drat since it's missing unit & integration tests |
Signed-off-by: juan131 <[email protected]>
Signed-off-by: juan131 <[email protected]>
|
Unit & integration tests added |
|
cc @wagoodman |
|
Hi @wagoodman, is there anything we can help with at this time? |
|
Hi @carrodher thanks for the ping! I'm sorry this sat for a while. I have some time in my calendar in the next few weeks to review this and get it in. Is this still something you all are interested in working on? If so, I think the main things to do first are get it up to date with Let me know how you all would like to proceed. Thanks! |
|
Hi @willmurphyscode, yes, definitely. Juan is now on PTO, but he will resume those contributions once he's back in a few days. |
Following #1397, this PR extends VEX support for ignoring/adding matches based on Vulnerability Exploitability Exchange data so it also accepts CSAF format.
The PR also refactors the
grype/vexpackage since now there's more than one supported VEX format (CSAF & OpenVEX) and it requires the vex processor to be able to distinguish between VEX formats and apply a different implementation.Credits to @joancafom as the designer of this implementation.
Use case
Given a CSAF VEX document such as the one below:
{ "document": { "category": "csaf_vex", "csaf_version": "2.0", "notes": [ { "category": "summary", "text": "Example Company VEX document. Unofficial content for demonstration purposes only.", "title": "Author comment" } ], "publisher": { "category": "vendor", "name": "Example Company ProductCERT", "namespace": "https://psirt.example.com" }, "title": "AquaSecurity example VEX document", "tracking": { "current_release_date": "2022-03-03T11:00:00.000Z", "generator": { "date": "2022-03-03T11:00:00.000Z", "engine": { "name": "Secvisogram", "version": "1.11.0" } }, "id": "2022-EVD-UC-01-A-001", "initial_release_date": "2022-03-03T11:00:00.000Z", "revision_history": [ { "date": "2022-03-03T11:00:00.000Z", "number": "1", "summary": "Initial version." } ], "status": "final", "version": "1" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version", "name": "2.6.0", "product": { "name": "Spring Boot 2.6.0", "product_id": "SPB-00260", "product_identification_helper": { "purl": "pkg:apk/alpine/[email protected]?arch=aarch64&upstream=openssl&distro=alpine-3.17.3" } } } ], "category": "product_name", "name": "Spring Boot" } ], "category": "vendor", "name": "Spring" } ] }, "vulnerabilities": [ { "cve": "CVE-2023-1255", "notes": [ { "category": "description", "text": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.", "title": "CVE description" } ], "product_status": { "known_not_affected": [ "SPB-00260" ] }, "threats": [ { "category": "impact", "details": "Class with vulnerable code was removed before shipping.", "product_ids": [ "SPB-00260" ] } ] } ] }You can use it so Grype suppresses the vulnerability which status is
known_not_affectedgiven the justificationClass with vulnerable code was removed before shipping: