On 6.02.2025 13:15, Jarek Potiuk wrote:
I agree that we should only publish VEXes for the currently supported
version (i.e. usually the most recent one).
Do you know if there is a way to "unpublish" VEX's ? (mark them not
maintained).
Because that is what will effectively happen, we will have to start
publishing new VEX's for the latest version and make sure that all the
consumers of previous VEX know it's not maintained any more.
In CycloneDX you can specify, which versions of your component are
affected by a CVE[1]. There are 3 states "affected", "unaffected" or
"unknown". We can use the last status for versions that are no longer
maintained.
If the VEX file itself becomes unmaintained, currently you probably need
to rely on the same heuristic that you use to check if an OSS project is
alive: if the timestamp in the VEX file is a couple of years old, the
file is unmaintained. This is probably not a problem, since currently
VEX-es are not required. If a downstream project needs some information
from an OSS project, they can do the analysis themselves and make a PR.
In the midterm future the Common Lifecycle Enumeration will be ready and
consumers can use that data to check if the VEX file is maintained. The
definition of `endOfSupport`[3] in the initial draft[2] describes the
end of support as:
```
Indicates when the manufacturer ceases any and all support of a
component or service. This point in time marks a transfer of risk from
the manufacturer to the consuming organisation or user of the component
or service, encompassing all cybersecurity knowledge and known
vulnerabilities, with no further assistance provided by the manufacturer.
```
Basically, once EOS is reached the VEX can be considered unmaintained.
[1] https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_affects
[2] https://github.com/Ecma-TC54/tg3/pull/3
[3]
https://github.com/Ecma-TC54/tg3/blob/db8c721628c03bde3846cff3169ce37bb0349a08/SPECIFICATION.md#endofsupport
As long as they are published in a way that we can discover them
automatically - which is not the case currently, but hopefully transparency
exchange API will make it possible,
If you can find an SBOM, you can find VDR-s and VEX-es via external
references. In the Maven world, where SBOMs can be identified via a
naming convention (not a formal spec), you can already do it.
I guess also there will be a long tail
of projects that do not have VEX's or VDRS or SBOMS for years to come, so
the question is what we do with those dependencies? But I am afraid we are
a few years from even a small percentage of our deps to support it. And if
our users are regulators, ask us - what do we say? We need to have a good
answer prepared.
There will be dependencies without SBOMs for at least a decade. The Java
Platform Module System was introduced in 2014. Today there are still
basic libraries, which are not modules and you can not (reliably) use
them in a modular library. JPMS can be harder to implement than SBOMs (I
think it is not an accident that the abbreviation ends in PMS), but for
simple libraries it is not difficult. You can contribute JPMS support to
upstream projects. Sometimes they accept it, sometimes they don't.
With SBOMs we can do something similar: we can contribute SBOM
generation and VEX entries, but if they don't want to, we tell users
that we can not (reliably) publish VEX-es, because upstream projects
don't do it.
Good example is a Werkzeug dependency (that we did such analysis on):
* Airflow 2 uses Werkzeug - transitively through several of our dependencies
* For quite a while there is a known and serious vulnerability in Werkzeug (
https://github.com/apache/airflow/discussions/44865 - CVE-2024-49767) in
version 2.2.3 we have - fixed in version 3.0.0 . We believe it does not
affect us as we do not seem to use that feature that affects us (uploading
files) - but we are not sure, because this dependency is used by about 5 or
6 other dependencies of ours - not directly by us - and we have not done
complete analysis of those - that would require a lot of digging and
analysing 3rd-party code to that we have no expertise in.
…
Our users (happened multiple times) DEMAND from us to remove that
dependency, because it is shown in their scans as critical. And it's not
the image. The Werkzeug dependency is installed every time Airflow is
installed - version 2.3.0 that is vulnerable and we cannot do anything
about it - until Airflow 3.
Nice conundrum! I think we should solve it by clearly specifying the
limits of our cybersecurity information. All the deps are OSS, so users
simply need to ask all the projects between Airflow 2 and Werkzeug to
provide an official statement. Once they do that, Airflow can provide a
statement based on that information.
This is why I would like to start publishing VEX-es for libraries
(almost) on the bottom of the dependency stack. Without that information
commercial application manufacturers will spend millions in security
analysis. They can as well use some of that money to crowdfund VEX-es in
OSS projects.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
