Scanning your Conda environment for security vulnerabilities
You don’t want to deploy an application that has security vulnerabilities. That means your own code, but also third-party dependencies: it doesn’t matter how secure your code is if it’s exposing a TLS socket with a version of OpenSSL that has a remote code execution vulnerability.
pip-based Python applications, you’d usually run vulnerability scanners on Python dependencies like Django, and on system packages like OpenSSL.
With Conda, however, the situation is a little different: Conda combines both types of packages into one place.
In addition, most vulnerability scanners don’t support Conda.
Let’s see what makes Conda different, and how you can scan packages for known vulnerabilities.
The Conda difference
Typically for a Python application, C libraries like OpenSSL and applications like Nginx would come from a Linux distribution like Ubuntu, and Python dependencies would be installed from PyPI using
Additionally, Python binary packages (“wheels”) can include shared C libraries they depend on.
Conda uses a different model: the Conda package repositories have packages for C libraries, C applications, Python libraries, and so on, all in one place. Instead of some packages coming from the Linux distribution, and some from the Python package repository, everything gets installed from the same place.
In practice, Conda relies on the system C library, so you still want to run a security vulnerability on the underlying Linux distribution’s system package. But the bulk of security vulnerabilities, whether it’s OpenSSL, Nginx, or a Python package, will come from Conda packages.
Security vulnerability scanners that are built for checking Python dependencies are not sufficient for Conda because they only understand Python packages.
For example, let’s say I have a Conda environment with some security vulnerabilities.
I can use the
safety tool to find security vulnerabilities in Python packages:
$ conda activate example (example) $ pip install safety (example) $ safety check ... +==================+===========+=============+==========+ | package | installed | affected | ID | +==================+===========+=============+==========+ | pip | 20.2.4 | <21.1 | 40291 | | cryptography | 3.2.1 | <3.3 | 39252 | | cryptography | 3.2.1 | <3.3.2 | 39606 | +=======================================================+
And that works… but it won’t catch problems in the Conda packages that aren’t Python packages.
Jake: a vulnerability scanner for Conda
In order to scan for all security vulnerabilities, we need a tool that knows about all the different types of software that end up in the Conda package repositories, beyond just Python libraries. The only tool I know of that does is Jake, which relies on the Sonatype OSS Index of security vulnerabilities.
To begin with, Jake also supports
(example) $ pip install jake ... (example) $ pip list | jake ddt | grep VULNERABLE [38/39] - pkg:email@example.com [VULNERABLE] [39/39] - pkg:firstname.lastname@example.org [VULNERABLE]
There’s a lot more details in the output if you omit the
One thing to notice is that
safety doesn’t know about the Jinja vulnerability, for some reason, and Jake in turn missed the
pip vulnerability that
safety knew about.
None of the tools or underlying databases will catch everything.
pip packages, Jake also supports Conda packages, and this is where it goes far beyond what Python-specific tools can do.
We need to use
conda list and the
-c option, and it’s very important not to omit the latter, otherwise it will just give you Python vulnerabilities.
With those options, you can find security vulnerabilities in all the Conda packages:
(example) $ conda list | jake ddt -c | grep VULNERABLE [59/63] - pkg:email@example.com [VULNERABLE] [60/63] - pkg:firstname.lastname@example.org [VULNERABLE] [61/63] - pkg:email@example.com [VULNERABLE] [62/63] - pkg:firstname.lastname@example.org [VULNERABLE] [63/63] - pkg:email@example.com [VULNERABLE]
Security vulnerabilities tools that scan only Python packages would never find a vulnerability in OpenSSL.
That being said: Jake doesn’t yet support Conda-Forge packages very well, mostly it focuses on the default Anaconda package channel.
Scan your dependencies!
Scanning dependencies for vulnerabilities is an important part of keeping your application secure. If you’re not already doing it, now’s a good time to take 20 minutes and add Jake to your CI pipeline.
Create production-ready Docker Conda images in just one hour
You're packaging your Conda-based Python application with Docker, and that means a whole new set of worries...
You've got huge 2GB images, rebuilding the image means waiting hours for Conda to resolve dependencies, and you're worried about the security of your image.
Learn the fastest, easiest way to get from the prototype Docker image you're running on your laptop to production-ready Docker images that are small, fast to build, and secure.
Free ebook: Introduction to Dockerizing for Production
Learn a step-by-step iterative DevOps packaging process in this free mini-ebook. You'll learn what to prioritize, the decisions you need to make, and the ongoing organizational processes you need to start.
Plus, you'll join my newsletter and get weekly articles covering practical tools and techniques, from Docker packaging to Python best practices.