> On 7 Feb 2025, at 09:11, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> The CRA mandates manufacturers to supply patches upstream, I wonder if
> this could be extended to VEX-es
>
> Actually, this is an interesting "take". I wonder if we can have some ways
> of publishing our VEX-es by a third party, not by us and allowing users to
> contribute there same as - making it effectively "crowd-sourced" and not
> "officially published by the ASF".
>
> I think if we can work it out and have such independent, trusted 3rd-party
> (parties?) where you could submit VEX information but not be "solely
> responsible" for the content in the VEX's, all my legal concerns are gone.
That’s an interesting take. There are situations where a third party attestation
in the form of a vex file makes sense. The question is how we publish and
discover
all relevant documents for a given product.
Right now the TEA solution focuses on what a single vendor has to say. When
discussing trust in a wider sense one need a trust and transparency
archictecture,
which may be what the SCITT WG in IETF is coming up with.
In my head, the VEX files applies to an SBOM for a single version of a single
product.
At some point, that version becomes problematic and I would like to find a clear
way to say “This version is replaced by the next version and you should NOT EVER
use this version. It’s the end of the line. Get out of here.” because there is
indeed
a vulnerability that will be fixed in a new release.
Another statement would be “there’s no known problems here at this date,
but we will now stop looking and you should get out of this series of releases.”
marking end-of-support.
/O
>
>
> On Fri, Feb 7, 2025 at 8:45 AM Piotr P. Karwasz <pi...@mailing.copernik.eu>
> wrote:
>
>> Hi Arnout,
>>
>> On 5.02.2025 12:19, Arnout Engelen wrote:
>>> On Wed, Feb 5, 2025 at 9:41 AM Piotr P. Karwasz<
>> pi...@mailing.copernik.eu>
>>> wrote:
>>>
>>>> if something happens to a transitive dependency, but all our direct
>>>> dependencies publish a "not affected" VEX statement, we can skip the
>>>> upgrade
>>> Possibly (or perhaps doing the update but not rushing a release)
>>
>> Sure, in ecosystems where the latest release is not chosen
>> automatically, we should always try to use the latest versions.
>>
>>>> and publish a "not_affected" VEX statement ourselves.
>>> In this case, shouldn't downstream projects consume that upstream VEX
>>> themselves? I'm not sure we should repeat that information.
>> Publishing a "not_affected" VEX statement would show that we did analyze
>> the CVE and the VEX file is maintained.
>>>> If a
>>>> direct dependency publishes an "exploitable" VEX statement and a nice
>>>> description of the conditions under which the bug can be triggered, we
>>>> can still check if we meet those conditions in our own code. We won't
>>>> have to analyze the code of our dependencies! Maybe we are not affected
>>>> and we can just publish a VEX statement that says so.
>>>>
>>> This would be interesting. It would also be nice to be able to accept
>> such
>>> statements/descriptions as contributions.
>>
>> The CRA mandates manufacturers to supply patches upstream, I wonder if
>> this could be extended to VEX-es.
>>
>> Piotr
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
>> For additional commands, e-mail:
>> security-discuss-h...@community.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org
