Repository navigation
Replies: 4 comments
|
Example of how #11331 can be used to rescore a vulnerability. If you scan Now if we generate CSAF-VEX report for that specific CVE, binary and dependency, we can rescore it in the context of your own product. {
"document": {
"category": "csaf_vex",
"csaf_version": "2.0",
"lang": "en",
"publisher": {
"category": "other",
"name": "Rancher Security team",
"namespace": "https://www.rancher.com"
},
"title": "CSAF VEX: CVE-2026-84303 assessment for k8s.io/kubernetes",
"tracking": {
"current_release_date": "2026-06-19T00:00:00Z",
"id": "openvex-cbf676b118a32bc533181fe44fa9c0809d45b8181910975fa623f26a83523d67",
"initial_release_date": "2026-06-19T00:00:00Z",
"revision_history": [
{
"date": "2026-06-19T00:00:00Z",
"number": "1",
"summary": "Initial CSAF VEX conversion from the OpenVEX statement; VEX status updated to affected."
}
],
"status": "final",
"version": "1"
}
},
"product_tree": {
"full_product_names": [
{
"name": "k8s.io/kubernetes",
"product_id": "CSAFPID-KUBERNETES",
"product_identification_helper": {
"purl": "pkg:golang/k8s.io/kubernetes"
}
},
{
"name": "google.golang.org/grpc",
"product_id": "CSAFPID-GRPC",
"product_identification_helper": {
"purl": "pkg:golang/google.golang.org/grpc"
}
}
],
"relationships": [
{
"category": "default_component_of",
"full_product_name": {
"name": "k8s.io/kubernetes with google.golang.org/grpc",
"product_id": "CSAFPID-KUBERNETES-GRPC"
},
"product_reference": "CSAFPID-GRPC",
"relates_to_product_reference": "CSAFPID-KUBERNETES"
}
]
},
"vulnerabilities": [
{
"cve": "CVE-2026-84303",
"flags": [
{
"date": "2026-06-19T00:00:00Z",
"product_ids": [
"CSAFPID-KUBERNETES-GRPC"
]
}
],
"notes": [
{
"category": "summary",
"text": "The product k8s.io/kubernetes is assessed as affected by CVE-2026-84303, with the vulnerability score set to the product-specific CVSS v3.1 value supplied for this assessment."
}
],
"product_status": {
"known_affected": [
"CSAFPID-KUBERNETES-GRPC"
]
},
"scores": [
{
"cvss_v3": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L",
"baseScore": 3.4,
"baseSeverity": "LOW"
},
"products": [
"CSAFPID-KUBERNETES-GRPC"
]
}
],
"threats": [
{
"category": "impact",
"date": "2026-06-19T00:00:00Z",
"details": "This assessment marks the product as affected. The supplied CVSS v3.1 score reflects the assessed impact for this product under the stated access and privilege conditions.",
"product_ids": [
"CSAFPID-KUBERNETES-GRPC"
]
}
],
"title": "CVE-2026-84303 in k8s.io/kubernetes"
}
]
}Now use the above CSAF-VEX report with the rescore and see that the same vulnerability is scored as low.
|
0 replies
|
@DmitriyLewen this is the discussion related to #11331. Please let me know what you think. |
0 replies
|
Great initiative! |
0 replies
|
+1, this is needed. Dependency-Track already applies the ratings from a CycloneDX VEX (since 5.1), and the CycloneDX spec now says consumers should use them to prioritize. Trivy only uses VEX to drop findings. I opened #10193 for the CycloneDX side (vens generates these ratings). Would be good to have one mechanism for CSAF and CycloneDX, happy to rework my PR on top of yours. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Description
Intro
One of the nice properties of VEX is that it allows a vulnerability's to be enriched with context about its applicability on a specific product, for example, if it's a false-positive or not (see NTIA VEX spec and CISA VEX spec). CISA's VEX Use Cases document mentions about vulnerabilities' score and other resources that can be added to a VEX document.
Problem
There are cases where a vulnerability is actually exploitable in a product, but it's severity differs from the upstream source of the vulnerability. For example, NVD can say that CVE-XYZ has a critical severity. Then vendor A triages the vulnerability and says that its product P has the vulnerability, but due to how the product is built, then impact of the exploitability of CVE-XYZ in P1 is actually medium due to other compensating controls available in the product. In this scenario, vendor A cannot emit a VEX report stating that vulnerability CVE-XYZ is
not_affectedin P1, and letting the scanner rate it as critical can lead to noise and unneeded concerns from customers. Thus providing a specific score for vulnerability CVE-XYZ in P1 as medium would provide better and more actionable information to its customers.Market solution
Security advisory and VEX format specs like CISA-VEX and CycloneDX allow to enrich their reports with specific severity for vulnerabilities. The OpenVEX spec doesn't support this, but a request for it was made in openvex/spec#31 (by an ex-Aqua employee) and proposed in openvex/community#24 (by myself).
Given that CSAF-VEX supports specific vulnerability scoring information and that Trivy can use CSAF-VEX reports to read false positive information about vulnerabilities (including in Trivy's own VEX Hub spec), a PR was proposed in #11331 to allow Trivy to consume severity information on CSAF-VEX reports.
Disclosure context
For context, I'm a SUSE employee and we rely heavily in OpenVEX and Trivy's own VEX Hub spec to provide contextual information of non-applicable CVEs in hundreds of containers images that we publish, see our our VEX Hub in
rancher/vexhub. This was a game changer for us, because we can easily and in a standard way provide reliable and curated information about CVEs in our images to our customers and help them to remove the noise about false-positives.Now we are facing another problem related to the fact that some CVEs are overrated by their upstream providers (be them NVD, MITRE, their own vendors etc.). This is understandable, because they have to consider always the worst case scenario that a CVE can affect a user. But given that not all CVEs impact different products in the same way, we want to communicate accurate severity information about such CVEs to our customers, and we see CSAF-VEX (already supports the scoring information) and OpenVEX (doesn't support scoring yet) as the natural way.
Note: I'm more than happy to help maintain this subsystem in Trivy if needed.
Target
None
Scanner
Vulnerability
All reactions