These are most likely false positives. Is there someone who can help a bit here in analyzing the reported cases from twistlock here?
I had a similar situation with Apache YuniKorn. I did some analysis and with the help of YuniKorn developers was able to verify that the TW alarms are false postiives. I am unable to make any progress here as my knowledge of Airflow (and its source code) is very limited. Thanks. On Wed, Jan 18, 2023 at 11:17 AM Jarek Potiuk <[email protected]> wrote: > 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. >> >
