Hello Sahib, The image is published by the Airflow PMC, but this is a "reference" image and it is not an official release of the Foundation. It's just as a convenience (otherwise known as compiled) package ( https://www.apache.org/legal/release-policy.html#compiled-packages). This is a package that our users might use as a convenience, having packaging airflow and its "golden" dependencies at the time of release together - in the form of Docker Image. But it is not an official release of the ASF.
Fixing all reported vulnerabilities reported there is no goal for us - especially in such convenience packages. One of the reasons is that there are many false positives in such reports. We don't even look at those reports to classify them - mostly because they are coming from external dependencies and the process described below makes sure that future versions of the images will use latest versions of those dependencies - latest released applicable dependencies will be used. However, we take security VERY seriously in Airflow and there are multiple ways you and your company can address their high security expectations (but also give back your security-minded approach back to the community from which you have the software for free). Important thing you can do - because of the high level of high-positives, it would be a fantastic way of giving back by your company to use your security team to analyze them and if you find some of them turning into exploitable issues. And if you find ways to exploit them, you can report each issue you find back in a responsible way including reproducible steps - following the ASF security policy. https://www.apache.org/security/. Since you seem to be a security-minded user, this is absolutely the best you can do if you are running the scans. Any help from your side to get better and stronger security for the whole community will be much appreciated and reporting issues in a reproducible, individual way is cool. We get such reports from a number of researchers and users and we strive to act on them timely and appropriately. I hope you will help with that, since you are part of our community and are security minded. Also - if you really want to be on top of everything - you are completely free to build your own image with whatever new versions of dependencies that have been released since we last published the image. When we created the image we were preparing for the fact that some of our users would like to use the reference image of ours as a starting point, which will allow them to apply any level of high security standards they might have. And you are pretty much fully covered there, because we not only expected people like you would like to care about the security, but we also built tooling for that from the very beginning. 1) The binary images (reference, convenience packages) at the moment of publishing are always built using airflow latest official packages with latest security fixes, but they are also automatically built using latest available python base images (our process automatically takes the latest released Python images as the bass and all the dependencies we install use the latest available "debian-compatible" releases of system-level dependencies. 2) This is the same with Python dependencies - with every merged commit we automatically bump all dependencies of ours to the latest compatible version (see the history of such updates here: https://github.com/apache/airflow/commits/constraints-main - we have more than 650 dependencies and updating them manually by hand is not really possible, so we worked out a system that does it automatically - sometimes we have 5-10 updates a day. As a result, what you have in the image is the "latest released, compatible" set of dependencies. With every new release of the image, the "latest and greatest" set of "golden" dependencies are released. Taking into account 1) and 2), one of the best ways to keep your deployment secure is to make sure you update Airflow to the latest released version as soon as a new version is released. It is one of the best ways you can keep your deployment secure. I suggest you establish such a policy in your company - to update Airflow to the latest released version asap. If you are security-minded, this is an absolute must I think. 3) But if you want to keep on being continuously updated with the latest fixed dependencies, even without Airflow upgrade, you are still able to do it. Even every day if you want without waiting for Airflow to be released. While we are not rebuilding the images after release usually (there are some critical cases when we do) you are completely free to build the images on your own and a) use latest released system dependencies b) upgrade any python dependencies to newer versions when ready. Similarly to what we do - you can set up automated updates of the dependencies if you want - you can take our automation as a base. Our approach to do it is decribed in our docs and you can follow it to build your own approach https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst#dependency-management . The way how to build your image with the latest dependencies is described in this doc - where we explain how to build airflow image using "customisation" approach - https://airflow.apache.org/docs/docker-stack/build.html#customizing-the-image. You can fully automate this process if you are really security conscious. The tools and approach we developed in the community provides a very good people for such an automation - it was designed to support precisely this workflow when we developed the Airflow image/Dockerfile. 4) Finally - if you have even more requirements for security you can pre-vet and prepare your own versions of any dependencies your company considers as secure and build the Airflow image in an Air-Gapped environment. Some of our users who are security-minded asked for it and our Dockerfile is rather versatile in this regard - we have the whole chapter about "Building the images in security restricted environments'' - https://airflow.apache.org/docs/docker-stack/build.html#build-images-in-security-restricted-environments - it shows how you can prepare and build "offline" installation of dependencies to build Airflow image, and if you care and want to use different, compatible dependencies or secure them by patching, you are completely free to do it. I hope the answers you get are complete and allow you to find the best way to not only proceed with your security approach but also give back to the community. J. On Wed, Jan 18, 2023 at 3:08 PM Sahib Aulakh <[email protected]> wrote: > For a client in the financial industry, in order to use Airflow, we have > to pass the security scans from Twistlock ( > https://www.cloudfoundry.org/the-foundry/twistlock/). Twistlock is > currently raising the following issues at CRITICAL level for the > apache/airflow:2.5.0 image:(1) > https://nvd.nist.gov/vuln/detail/CVE-2021-46848. > (2) https://nvd.nist.gov/vuln/detail/CVE-2022-32221. > (3) https://nvd.nist.gov/vuln/detail/CVE-2022-47629. > (4) https://nvd.nist.gov/vuln/detail/cve-2019-17495.I am relatively new > to Airflow and seek some guidance as to how to make progress on this issue.(a) > Are these known issues? > (b) I understand that a lot of alerts from twistlock can be spurious due > to libraries in the base image which are not being used, etc. Do these > alerts fall in that category (that is, can these be dismissed as false > positives)?Any help with analyzing these will be appreciated.Thanks. >
