swagger-ui version causes security findings

[montgomery-marcus-solute]

Apache Airflow version

2.4.0

What happened

My organization scanned a container running airflow 2.4.0 and found the following vulnerabilities, all related to swagger-ui, fixed in the swagger-ui version next to the link for the vulnerability:

https://nvd.nist.gov/vuln/detail/CVE-2019-17495 >= 3.23.11
https://nvd.nist.gov/vuln/detail/CVE-2018-25031 >= 4.1.3
GHSA-388g-jwpg-x6j4 >= 3.0.13
GHSA-x9p2-fxq6-2m5f >= 3.18.0
GHSA-4f9m-pxwh-68hg >= 3.20.9
GHSA-qrmm-w75w-3wpx >= 4.1.3

What you think should happen instead

If possible, please update the swagger-ui version used in airflow to the latest or at least version 4.1.3 or greater.

How to reproduce

No response

Operating System

ubi8

Versions of Apache Airflow Providers

No response

Deployment

Other Docker-based deployment

Deployment details

No response

Anything else

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[uranusjr]

This sounds like an important issue to you. Do you want to submit a pull request?

[potiuk]

Please in the future @montgomery-marcus-solute avoid publicly discusssing potential security issues. This is not responsible behaviour and it should be avoided. There are better ways you do it if you want to behave responsibly.

We are following the rule that almost all of our dependencies are automatically upgraded in the new releases (see https://github.com/apache/airflow/blob/main/dev/REFRESHING_CI_CACHE.md#manually-generating-constraint-files).

We upgrade all dependencies automatically whenever we can and run automated tests on them, and bump constraints when they succeed. So your best bet is to always upgrade to latest possible version immediately when it is realeased (please follow announcements in [email protected]).

In the rare circumstances we have upper-bound we have good reasons for those and those are clearly documented in our https://github.com/apache/airflow/blob/main/setup.cfg and you are free to try to upgrade those and solve any issues in a PR as @uranusjr mentioned.

Following Apache Security Team approach, we are not following issues that are result of blanket unverified results of security scans. Those security scans often contain false positives. The fact that some version of software has a CVE assigned, it does not mean that the user is affected. This is a lot of noise and it makes more harm than it brings benefits. But If you actually find that one of the vulnerabilities affects airflow, you are absolutely welcome to report it in a responsible way - not via public issue but following our Security Policy.

You are supposed to submit the issue with reproduction scenario via the private email mentioned in the policy. But only when you find that Airflow is vulnerable and you have both reproduction scenario and explanation why this security issue is important.

Side comment. We do not have dedicated security team in Apache Airlfow. But as a security conscious user who has dedicated security team and organisation that is security conscious, this is the least you can do to pay back for the free software you get if you dedicate your skills and resources in analysing the CVEs and seeing if they are actually valid security issues. Please exercise that opportunity if possible.

[montgomery-marcus-solute]

My apologies. At first I thought about submitting this as a security issue but the wording at https://github.com/apache/airflow/security/policy seemed to say that would only be for newly discovered vulnerabilities and since these findings are already public, I went with the bug report. Still, I can see now that aggregating all that public information in one place maybe wasn't the best idea.

I don't have the know how to write a bug fix myself. Hopefully I will in the future. Thanks for your reply, and you can close this.