shahar1 commented on code in PR #61956: URL: https://github.com/apache/airflow/pull/61956#discussion_r2810038534
########## airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst: ########## @@ -0,0 +1,159 @@ + .. 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 a rather large 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 and 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 a 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. + +This general approach is described in the `Apache Software Foundation's approach <https://security.apache.org/report-dependency/>`_. +This document provides more detailed instructions that are specific to Apache Airflow. + +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 to 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 +--------------------------------------------------------- + +There is a chance that you are using some scans that will show you CVE in a 3rd-party dependency that is +used by Airflow and you would like to get rid of those. There are a few things you can do in such case: + +* First of all - resist an urge to open a public issue - especially if you have no idea if Airflow and your + deployment is impacted. Such issues will be usually closed with reference to this document and you + will be expected to follow it. + +* Check if you can upgrade yourself to the newer version of dependency that is not vulnerable to the CVE, and Review Comment: ```suggestion * Similar to GitHub issues, do not open a PR that exposes details of a potential CVE or security vulnerability before it has been properly reviewed and responsibly disclosed to the security team, and explicitly approved by them to proceed with a fix PR according to their instructions. * Check if you can upgrade yourself to the newer version of dependency that is not vulnerable to the CVE, and ``` It's also important to refer to PRs (currently absent from docs), as people might open them directly instead of reporting them first -- 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]
