At ActiveState, we often run into organizations that still have older versions of programming languages deployed in non-production environments. Since these instances are not public facing, the reasoning goes something like, “The code may be insecure, but it’s not likely to get hacked, so there’s no real business case to fix/upgrade it.”
In the past, this kind of argument has been reasonable enough. However, times have changed: 

And this year has seen a further 650% increase in supply chain attacks. 

If you’re still running Python 2 code in non-production, you need to realize that the Python 2 supply chain spans more than just the increasingly vulnerable Python 2 interpreter and third-party packages in the Python Package Index (PyPI). The supply chain also includes the ways in which Python 2 is involved in your build process, as well as how it may be used/running in your development and test environments. 

For example, you may still have Python 2-based tools, test automation services or even scripts incorporated in your CI/CD framework, command-line interfaces or deployment infrastructure, all of which now pose a growing security threat as Python 2 vulnerabilities continue to grow. If you’re concerned about this issue (and you should be), you essentially have three choices:

• Undertake an upgrade/rewrite of your Python 2 systems
• Patch and maintain the systems yourself
• Find a third party to supply Python 2 security fixes for you, like ActiveState

To help you assess the threats posed by Python 2 in your non-production environments, let’s take a look at some of the software development processes you probably employ today, including how you import third-party code, build software artifacts, and then run/use that software.
ActiveState also provides a free assessment of your Python 2 code.

Importing Python 2 Packages

According to PyPIstats.org, the average number of Python 2 package downloads (using the most popular package, urllib3, as an example) hasn’t changed dramatically in the almost two years since Python 2 was declared EOL:

Dec 2019 to Jan 2020:

Sept 2021 to Nov 2021:

While the proportion of the Python 2 downloads of urllib3 has gone from ~50% of all downloads two years ago to ~16% today, in absolute terms, daily download volume remains the same at ~1.5M. The implication is that new Python users have adopted Python 3, but older users continue to work with Python 2. That’s a large number of organizations downloading a package that currently has both a high and medium vulnerability unpatched by the community. 

And if you’re still working with Python 2, you’re likely using more vulnerable packages than just urllib3. Check the ActiveState CVE Updates page to see the list of security fixes we’ve patched since Python 2 EOL’ed.

Building with Python 2 Code

Prior to the SolarWinds attack in December 2020, developers have rarely considered their internal software development processes and infrastructure to be a common target of hackers. But given recent trends, software build environments are becoming a key way for bad actors to compromise software vendors, often by injecting malware into patches, updates and even new versions. When a vendor’s customers install the new code, attackers gain access to thousands or even tens of thousands of potential targets via their single supply chain hack.

If you’re like some of our customers, your automated build system may be using Python 2 for something as innocuous scripts that verify/record test results, or else for more critical steps like building the container/VM environments, or distributing/deploying built artifacts.

With the evolving threat landscape, none of these processes should be considered untouchable simply because they are internal processes. 

Running Python 2 Code

There are multiple examples of huge, public-facing Python 2 codebases that have by and large been migrated to Python 3. From Instagram’s migration that took a relatively quick ten months to Dropbox, which took three years to JP Morgan’s Athena that took even longer, Python 2 code in production is a well-known and increasingly well-addressed issue. 

But migrating or rewriting Python 2 applications isn’t always cost-effective, since the resources and time you need to expend in order to eventually end up with the exact same thing (just in a new codebase) is far too high.

If you’re still working with Python 2 code, you’re running it in more locations than just production environments. Two of the most common examples include running unit tests in internet-connected development environments and running various tests in non-hermetically sealed containers (i.e., containers that have an internet connection) as part of your CI/CD pipeline. 

Both instances offer bad actors key points of attack, especially if you’re not keeping current with the latest set of reported Python 2 vulnerabilities.

Conclusions: Secure Non-Production Python 2 Code Now

In many cases, it just makes no business sense to migrate your Python 2 code to Python 3. But if you’re still using Python 2 in your supply chain, which spans your import, build and run processes, your risk is growing exponentially as more Python 2 security vulnerabilities are reported. 

Simply burying your head in the sand and counting on the fact that non-production systems are unlikely to be hacked amounts to willful ignorance in 2021/22. It’s not a matter of if you’ll get hacked, but when. While you could spend time and resources to address Python 2 security issues, your developers can usually deliver far more value to your organization by focusing on their current tasks.

Need More Information?

• Understand how Python 3 vulnerabilities are impacting Python 2
• Read our datasheet on Python 2 Extended Support
• Read about how Python 2 users prepared for Python 2 EOL
• Understand the state of software supply chain security with our latest survey report

Recommended Reads

Python 2 EOL Report Card – Is the Industry Ready?

Python 2 to 3 Migration: A Developer’s Experience

Python 2 EOL – Now What?