Hi Jarek,
On 6.02.2025 10:52, Jarek Potiuk wrote:
I can think of one way we could make it manageable - we only publish VEX's
for the last released version in the "maintained" line of a package - that
could give better chances that what is there is "right" - and reject any
requests and questions about past versions - essentially "freeze" VEXs for
previous versions when we release a new one. That **might** have a chance
to work, because in the vast majority of cases the CVES found in 3rd-party
libraries will be for old versions of those that we won't use already in
the last version. That would dramatically drop the exposure for users
asking for state (providing that we automate that and filter out
automatically and reject the questions about past versions - it's pretty
doable). We could even - in this case make a dependabot-style automated and
proactive work, whenever a vulnerabilty is detected in a library, we could
see if it is already updated in the "in-progress" version and act
accordingly and automatically publish state in the last VEX "in_triage" for
example, and maybe have a way to manually review and update those (but only
for last released version in the maintained line). We could allow
indefinite "in triage" in this case if we are not sure, and maybe sometimes
- very rarely we could put "not affected". but that would be a unicorn
IMHO.
But then - except the few exceptions - there is no real value from having
such VEXs if you ask me. That will become a cargo cult very quickly.
I agree that we should only publish VEXes for the currently supported
version (i.e. usually the most recent one).
Since looking through somebody else's code is error-prone and time
consuming, I would restrict the generation of VEX statements to the
following two situation:
1. The CVE is in a dependency that is only used by your project, not
your project's dependencies. In this case you can directly read the CVE
(or VDR document) and identify if you use the affected feature in your code.
2. The CVE is in a transitive dependency. In this case you wait until
all your **direct** dependencies potentially affected publish a VEX
statement. Only then you publish a statement based on what your
dependencies say in their VEX records.
Note the the utility of VEXes varies greatly between ecosystems. In the
case of Python applications users download the application and its
dependencies directly from PyPI. Unless I am mistaken, if there is a
vulnerability in one of your dependencies, you don't need to make a new
AirFlow release, users can easily upgrade their system themselves.
VEX-es might be only useful to those that create an Airflow Docker image
to know if they need to regenerate it. They will probably do it anyway.
In the case of Java applications, all dependencies are bundled in some
downloadable archive (WAR, Zip, tar.gz). To upgrade those dependencies
the project needs to make a new release. VEX-es can help deciding if
they need to do it right now or they can wait with the upgrade until the
next scheduled release.
My preferred example is applications like Kafka that recently switched
to Log4j 2 Core and use YAML as configuration format. We parse YAML
through Jackson, which uses SnakeYaml as low level parser. What happens
if SnakeYaml has a CVE[1]?
* If something like CVE-2022-1471[2] happens, the Jackson team will
create a "not_affected" VEX record and Log4j Core will pass the same
result to Kafka. Note that this will not generate a lot of additional
work for the Jackson team, since they provided a human-readable version
anyway[3]. It could even generate less work, if users consume the VEX file.
* If something like CVE-2022-38752[4] happens, the Jackson team will
create an upgrade recommendation for those that parse untrusted YAML.
Log4j Core will generate a "not_affected" VEX record (we only use YAML
to parse a config file) and yet again Kafka does not need a new release.
Again, Jackson had to deal with a user question about it[5], so a VEX
statement will not generate a lot of additional work.
Summarizing: let us restrict VEX-es to the current version of our
projects and publish them only when the CVE has been analyzed by all our
"suppliers". We should be open to external companies helping us with the
analysis through PRs, but let us not do any additional work ourselves.
Of course there are exceptions: when Log5Shell happens, we can do the
entire analysis ourselves.
Piotr
[1]
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Asnakeyaml_project&cpe_product=cpe%3A%2F%3Asnakeyaml_project%3Asnakeyaml
[2] https://nvd.nist.gov/vuln/detail/CVE-2022-1471
[3] https://github.com/FasterXML/jackson/discussions/141
[4] https://nvd.nist.gov/vuln/detail/CVE-2022-38752
[5] https://github.com/FasterXML/jackson-dataformats-text/issues/342
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org
