Hi Jarek,
On 6.02.2025 09:22, Jarek Potiuk wrote:
I don't see how VEX introduces a new risk here.
It really depends on whether the VEX entry states: "Not affected" or
"Possibly not affected". As you see in my responses - those are exactly
what I am explaining in my responses is exactly what you explained. In one
of those issues I responded to the user that "we do not use that affected
functionally, so likely we are not affected". But yet the user demanded,
and expected and was very persistent about it, to have 100% certainty and
an authoritative answer.
I am absolutely fine in putting in VEX:
* don't know, did not check (when we did not want to spend days
investigating it and it's difficult)
* possibly not affected (when we think we are not affected)
* affected, please upgrade (when we know)
I think I understand, where the problem lies. Looking only a
CycloneDX[1] there are two important fields to describe a VEX entry:
* A `state` field with values in: resolved, resolved_with_pedigree,
exploitable, in_triage, false_positive, not_affected. There is no
"possibly not affected" state.
* A `detail` field, where we describe the problem to humans, including
how we did come to a certain conclusion:
```
Detailed description of the impact including methods used during
assessment. If a vulnerability is not exploitable, this field should
include specific details on why the component or service is not impacted
by this vulnerability.
```
I believe that as long as we fill in this carefully, the risk for the
Foundation is minimal. The whole point of publishing a VEX statement
(currently optional) is NOT to use an `exploitable` state and write "We
did not perform any exploitability analysis, but unit/integration tests
show that the patched version of `libfoo` is compatible with our
library. Please upgrade the vulnerable component."
Piotr
[1] https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis
