jscheffl commented on code in PR #61956: URL: https://github.com/apache/airflow/pull/61956#discussion_r2809692682
########## airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst: ########## @@ -0,0 +1,132 @@ + .. Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +Vulnerabilities in 3rd party dependencies +========================================= + +How users should treat 3rd-party dependencies with known CVEs +------------------------------------------------------------- + +Apache Airflow has rather big number of dependencies, and we invest a lot of effort to keep Airflow updated +to latest versions of those dependencies. We have automation, that checks for new versions of dependencies, +and attempts to upgrade and test them automatically, we also have security scans that indicate if we have +minimum versions of dependencies, that are not vulnerable to known, important, exploitable CVEs. Every +version of Airflow has a set of constraints - i.e. latest tested versions of dependencies, that +are passing our tests and that we know allow to install Airflow an it's providers together. + +However - due to sometimes complex dependency trees and sometimes conflicting requirements, we are not +always able to upgrade and test dependencies to the latest versions. Sometimes we can only upgrade to newer +versions of dependencies in the "development" branch - i.e. for the next "MINOR" version of Airflow, +and we are not able to backport those upgrades to the latest released "MINOR" version of Airflow. + +This means that sometimes we have to keep older versions of dependencies in the latest released "MINOR" +version of Airflow, even if those versions are vulnerable to some CVEs. Since Airflow is volunteer-driven +project, we do not provide any guarantees that we will upgrade to dependencies that are CVE-free. + +Contrary to a common belief, the presence of a CVE in a 3rd-party dependency does not automatically mean +that Airflow or your deployment - and we do not accept reports and issues stating that we **should upgrade** +those because they have a known CVE. We need to have a proof that the CVE is exploitable in Airflow +and that it can be used to attack Airflow or your deployment and such proofs should be responsibly +disclosed to us, in private, following our `Security policy <https://github.com/apache/airflow/security/policy>`_. +If you have such proof, please share it with us and we will do our best to upgrade the dependency +to a non-vulnerable version as soon as possible and back-port it to latest released minor version, +following our :doc:`releasing_security_patches` policy. We expect our commercial users who need to fulfill +their obligation to manage and disclose CVEs in their environment to invest time and effort into +responsible disclosure, and investment of their security teams if they think Airflow is vulnerable to +third-party CVEs. + +Constraints in released airflow versions +---------------------------------------- + +The constraints we publish for released versions of Airflow are the latest tested versions of dependencies, +that we know worked with Airflow at the time of release. However, in many cases, if there are newer versions +of those dependencies released later, they have a chance to work with Airflow as well, as we usually do not +upper-bind those dependencies and you should be able to test and upgrade to newer versions even if the +constraint files have an earlier version of the dependency. + +We almost never (except in very exceptional cases which do not allow users to use constraints to install +airflow) update those constraint files after specific version of Airflow is released, and we do not re-publish +Airflow reference container images with updated dependencies, so users are on their own to update selected +dependencies if they want to, and test if they work with Airflow. What you can do in case your scans +show some CVEs that you need to update is described in :ref:`docker-stack:fixing-image-at-release-time`. + +The easiest way ti get latest, CVE-free dependencies is to upgrade to the latest released version +of Airflow and keep doing it frequently as we release, this will make it overall easier for the users +to handle the upgrade process when they do it incrementally and more often, rather than jump a number +of versions at once. + +What you do if you detect a CVE in a 3rd-party dependency Review Comment: Should we maybe also point the users to the 3rd party repo and propose and contribute a fix there? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
