Notice: While JavaScript is not essential for this website, your interaction with the content will be limited. Please turn JavaScript on for the full experience.

Securing Python Runtimes

Written by Dana Crane, ActiveState

When developing in Python the simplest and quickest solution for many developers is to grab whatever reputable packaged runtime environment you can find, where a runtime environment is defined as the Python language itself + popular third party packages + the interpreter. That way you can avoid having to:

  • Assess which third party packages can be trusted
  • Compile the packages from scratch
  • Resolve all the dependencies

For most Python developers, this has typically meant downloading Anaconda or ActiveState’s Python, ActivePython, or a similar commercial offering. Many of these distributions come with hundreds of pre-compiled and pre-verified popular Python libraries, and can be used for a variety of projects. Of course, for any one project you’ll probably end up using less than half of the included packages in your application.

Depending on your software development process, you might be creating separate Requirements.txt or Pipfile.lock files for production. At ActiveState, however, many of our enterprise customers are unable to modify their Python runtime environment (let alone create a new one) without getting the lawyers involved to reassess whether the open source licenses conflict with corporate policy, delaying their time to market. As a result, the runtime they build with is what gets tested, which is what gets shipped into production.

The Growing Security Problem

The latest security reports from open source security vendors like Synopsys (2018 Open Source Security and Risk Analysis https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/2018-ossra.pdf) and Snyk (The State of Open Source Security - 2019 https://snyk.io/opensourcesecurity-2019/) point out the fact that there’s an ever-escalating number of open source vulnerabilities reported against an ever-growing number of third party libraries. Indeed, WhiteSource now names Python as the fifth least secure programming language (https://www.whitesourcesoftware.com/most-secure-programming-languages/). And, as Figure 1 illustrates, the number of application security breaches continues to escalate every year.

Data Breaches by Industry
Figure 1: Data Breaches by Industry

Certainly not all of these issues can be blamed on bloated runtime environments, but they don’t help matters. This is especially true when vulnerabilities are discovered in packages that have been included in the runtime, but not actually utilized by the application. These “false positives” still need to be investigated and resolved.

Unfortunately, these kinds of vulnerabilities have to vie with new features and bug fixes for precious velocity points in any development sprint. As a result, security tasks typically get deprioritized and pushed to the next sprint, where they have to vie for velocity points all over again. In fact, a recent study https://snyk.io/opensourcesecurity-2019/ shows that the median time from when a vulnerability is found until it’s fixed is over 2 years.

Minimizing Runtime Management

Python developers aren’t unique - we’d prefer to follow security best practices with respect to runtimes, but not if it’s going to prevent us from getting our sprint coding tasks done.

At ActiveState, we’re intimately familiar with the amount of work it takes to create and maintain multiple runtime environments (it’s what we do for a living). But for many enterprises, it can be just too costly to create tailored runtimes for each project, let alone runtimes tailored for:

  • Development - including all those packages developers or data scientists want to experiment with, but will never ship.
  • Testing - including all the functional and integrated test instances (in which the runtime needs to include all the test harnesses), plus all the security and performance testing instances (in which the runtimes should feature only those packages being deployed to production).
  • Production - which should contain the smallest runtime environment that will support the application in order to minimize the potential attack surface.

The ActiveState Platform provides a new option for Python developers. It makes it simple for anyone - not just build engineers - to automatically create runtime environments for their project on popular platforms. Just:

  1. Pick a Python 3 version
  2. Pick a platform to deploy on (Linux today, with Windows, Mac and Docker coming)
  3. Choose from among a set of popular PyPI packages you want to include

The ActiveState Platform automatically pulls in all dependencies, resolves them, and builds your Python runtime environment for you. In other words, a single person, in about an hour, can create runtimes for each environment - dev, test and production - that their project will get deployed to. This same task might take a team of dedicated build engineers weeks to accomplish.

More importantly, the ActiveState Platform will soon automatically update your runtime environments as vulnerabilities are found and new packages are released, reducing your workload to just verifying it against your automated CI/CD chain.

To try it out, you can sign up for an account at https://platform.activestate.com/create-account.