Python comes in many flavors, offering Pythonistas more than one way to accomplish their tasks. But for developers, the key criteria for making a choice between Python ecosystems usually comes down to:

• Does it make my life easier?

• Does it solve a key problem none of the other flavors can?

• Does it expose me and my organization to undue risk? (aka, am I going to get fired for using this?)

While no one ever got fired for using community Python, it tends to lag behind the capabilities of alternative Python ecosystem vendors like Anaconda and ActiveState (and to a lesser extent Linux vendors, as well). For example, community Python continues to lack key features that other Python ecosystems provide, including:

• Advanced dependency resolution, to ensure your environment won’t break when upgrading specific packages, for example.

• Vulnerability flagging to help you understand whether a package is vulnerable before you install it.

• Signed packages to help ensure that pre-compiled binaries aren’t modified before use.

• A secure build service that ensures packages are built from vetted source code.

• Software attestations that prove the provenance (aka origin) of Python packages.

All of which can decrease security risk, which is a key consideration when the Python supply chain is more and more under attack from typosquatting, dependency confusion and other exploits.

But there’s a cost to adopting new tools in order to gain these features, not only in terms of dollars but also in terms of learning curves, changes to dev processes, etc. This post looks at some of the tradeoffs to adopting an alternative Python ecosystem, and why you might want to try one.

Anaconda: The All or None Approach

The Anaconda Python ecosystem is extremely popular. It offers either the precompiled Anaconda distribution of more than 400 packages that makes for easy installation and setup, or else Miniconda, which contains just a version of Python, the Conda package manager, and a few necessary/convenient packages.

As I’ve asserted in a previous blog post, larger distributions like Anaconda increase the attack surface of your environment, and also increase the number of packages that could be vulnerable at any point in time. With supply chain attacks that target development environments on the rise (from SolarWinds to Codecov to Apache Netbeans IDE hack to the ShadowPad backdoor), starting with a minimal installation of Miniconda and building up your environment using their included package manager (Conda) may be a better approach.

But before you install a package with Conda:

• You’ll want to check to see which packages are currently vulnerable (either via the UI, API or Command Line Interface) before compromising your environment, as conda will happily install vulnerable packages without warning.

• You’ll want to check to see if it’s available, or else build it yourself using Anaconda’s conda forge, which (at least for popular packages) will automatically build the package from source for you. If you trust the CI providers, creating your own build in this way can be far more secure than installing an unsigned, prebuilt package.

Conda will then install the package, automatically resolve dependencies (including non-python dependencies), and flag any conflicts that may arise to ensure a consistent environment, including for virtual environments, which are natively supported.

To recap:

Depending on your needs, Conda can make your life easier and more secure, especially if you work on data science/ artificial intelligence projects that rely on binary packages like numpy, pandas, scipy, tensorflow, jupyter notebook, spyder, and other machine learning, data analysis, data visualization and data management tools and packages.

ActiveState: The More Secure Approach

Much like Anaconda, the ActiveState Platform provides an alternative, cross-platform package management ecosystem for Python. As an Anaconda alternative, ActiveState used to offer ActivePython, but for security (and other) reasons we have moved away from it to a Miniconda-style approach, providing only a version of Python, a package manager (State Tool) and a few key packages.

The State Tool functionality delivers many of the same advanced package management and automation features as conda, including:

• Dependency resolution and conflict flagging in real-time

• Native support for virtual environments

• Vulnerability identification

• An automated build system (the AWS-based ActiveState Platform) that securely builds Python packages from vetted source code, including those with linked C, Fortran and Rust libraries

The difference between Anaconda and ActiveState primarily lies in the approach to software supply chain security. For ActiveState, security begins with vetted source code and a secure, SLSA Build Level 3-compliant build service that produces not only secure packages, but software attestations and a Software Bill Of Materials (SBOM) to prove it. This includes:

• A version of the Python programming language for Microsoft Windows, Mac or Linux

• All packages, as well as their dependencies, including:

  • Transitive dependencies (ie., dependencies of dependencies),

  • OS-level dependencies

  • Shared dependencies (ie., OpenSSL)

• Configurations (ie., metadata like version number, open source licenses, etc)

• Vulnerabilities for each component

A more comprehensive alternative to Anaconda, the ActiveState Platform imports ~the entire catalog of Python packages (sourced from PyPI, GitHub, and other repositories), including multiple versions of each component. In many cases, you can remediate vulnerabilities by simply selecting a newer, non-vulnerable version of a package. You can then rebuild a secure configuration of your runtime in minutes, and use a single command to update your local environment. In this way, you can ensure you always have secure dev and CI/CD environments with minimal effort/disruption.

Additionally, since all components are tracked though a workflow from import through the build process, and all changes to your Python environments are also tracked, you can always identify:

• The provenance (ie., source) of all components in your SBOM

• Who made which changes to your Python environment, and when they did it

The result is a complete audit trail for all packages in, modifications to, and users of your Python environment, allowing you to simplify forensic audits.

So to recap:

Conclusions: When Looking For An Alternative to Anaconda, Security Matters

For many data scientists and software development organizations, security is not top of mind. Instead, they foster a culture that “moves fast and breaks things” where, when it comes to writing Python code, rapid prototyping trumps security. But in a rapidly evolving cyber attack landscape that saw a 650% increase in supply chain attacks in 2020, fostering a DevSecOps approach to Python software development is more important than ever.

The DevSecOps movement has existed for many years to encourage better risk management by shifting security left. Instead of a culture where development and DevOps environments are rarely updated until a critical vulnerability is flagged (typically) late in the testing process, security should be baked in from the start, and developers and DevOps empowered to prioritize security updates. But when security gets in the way of meeting sprint goals, it’s often the first thing that gets dropped.

ActiveState Platform users can benefit from a simple remediation and environment update process that can save dozens of hours per vulnerability that would typically be spent investigating, patching (or waiting for a patch), rebuilding, testing and updating the environment.

While the ActiveState Platform does fit with your existing processes, there is a learning curve that will have a short-term impact on your team. However, the longer term benefits of greater security will more than make up for it.

Next steps:

• Sign up for a free ActiveState Platform account and try it for yourself

• Read about how to speed vulnerability remediation

• Read about how to shift security left without disrupting Dev and DevOps