- Does it make my life easier?
- Does it solve a key problem none of the 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 are free of malicious code.
- A standard build service that increases security over installing unsigned, prebuilt packages.
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 CLI) 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.
|Dependency Conflicts||Flagged||Not flagged|
|Virtual Environments||Native support||Third party (venv/virutalenv)|
|Binary Package Build System||Automated via Conda Forge||Manual|
|Vulnerability Identification||CLI command||Out of band|
Depending on your needs, conda can make your life easier and more secure, especially if you work on data science projects that rely on binary packages like numpy, scipy, tensorflow, etc.
ActiveState: The More Secure Approach
Much like Anaconda, the ActiveState Platform provides an alternative, cross-platform package management ecosystem for Python. As an alternative to anaconda, ActiveState used to offer ActivePython, but for security (and other) reasons 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 delivers many of the same advanced package management features as conda, including:
- Dependency resolution and conflict flagging
- Native support for virtual environments
- Vulnerability identification
- An automated build system (ActiveState Platform) for packages, including those with linked C and Fortran libraries
The difference between Anaconda and ActiveState primarily lies in the approach to security. For ActiveState, security begins with a Software Bill Of Materials (SBOM), which provides you with a comprehensive list of ingredients required to build your application because you can’t secure what you don’t know about:
- The version of Python required
- 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 license, etc)
- Vulnerabilities for each component
A more secure alternative to anaconda, the ActiveState Platform imports a comprehensive catalog of Python packages (sourced from PyPI, GitHub, and other repositories), including multiple versions of each component. In many cases, you can remediate vulnerabilities in your SBOM by simply selecting a 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 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.
So to recap:
|Dependency Conflicts||Yes, plus solutions to conflicts||Yes|
|Virtual Environments||Native Support||Native Support|
|Binary Package Build System||Yes||Yes|
|Signed Packages||No (coming soon)||Yes|
|Automated Vulnerability Remediation||Yes||No|
Conclusions: When Looking For An Alternative to Anaconda, Security Matters
For many software development organizations, security is not top of mind. Instead, they foster a culture that “moves fast and breaks things,” where 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.
- Sign up for a free ActiveState Platform account and try it for yourself
- Read about how to speed vulnerability remediation
- Read about how shift security left without disrupting Dev and DevOps