Python is a fast evolving, extremely popular programming language that’s driving the revolution in Machine Learning and AI. In response, releases of the Python core have been gaining momentum, from one release approximately every two years to yearly releases. But this also means that older versions are being dropped from support sooner, as well:

Release	Release Date	Security Support
3.11	3 months and 2 weeks ago (24 Oct 2022)	Ends in 4 years and 8 months (24 Oct 2027)
3.10	1 year and 4 months ago (04 Oct 2021)	Ends in 3 years and 8 months (04 Oct 2026)
3.9	2 years and 4 months ago (05 Oct 2020)	Ends in 2 years and 8 months (05 Oct 2025)
3.8	3 years ago (14 Oct 2019)	Ends in 1 year and 8 months (14 Oct 2024)
3.7	4 years and 7 months ago (26 Jun 2018)	Ends in 4 months and 3 weeks (27 Jun 2023)

This faster evolution has resulted in organizations focusing on older releases longer than they arguably should. For example, Python 3.7 remains the most popular version of Python by download volume despite the fact that support for security fixes will be dropped by the Python Software Foundation (PSF) just a few short months from now:

Source: PyPIstats.org

Unfortunately, this is nothing new. Outdated codebases have long been the norm across the software industry, not just in the Python community:

Source: Synopsis Open Source Security and Risk Analysis Report 2022

And as the Veracode State of Software Security report reminds us: 

“Open source libraries are constantly evolving: what appears secure today may not be tomorrow. Despite this dynamic landscape 70 percent of the time, developers never update third-party libraries after including them in a codebase.”

Arguably, you might have been able to get away with a non-secure Python codebase back when Python was little used. After all, while never a good policy, “security through obscurity” remains a common practice. But open source software now comprises the vast majority of today’s codebases, and more and more hackers are continuously finding better and better ways to exploit vulnerabilities and other weaknesses across the entire open source software supply chain. 

This blog can help you understand why this is, how we got here, and what the industry as a whole can do about it.

Non-updated Open Source Codebase Risk

It seems obvious that the longer you go without updating your Python codebase, the more vulnerabilities, bugs and performance issues will be uncovered. The result is that your application will pose a greater and greater security risk to anyone that runs it. But ever since the birth of open source software, security risk has been a secondary concern at best. 

Simply put, open source software lets us get to market faster and innovate more quickly since it promotes reusable code. These values have been instilled in the startups that have leveraged open source to leapfrog more conservative enterprises, resulting in today’s software culture, which can best be defined by the phrase “move fast and break things.” It shouldn’t come as a surprise when that is exactly what happens, but the thinking goes something like this:

“I might get hacked, but I will miss out on revenue.”

In other words, the opportunity cost of stopping to fix a vulnerability or upgrade a codebase is almost never worth the tradeoff of beating your competitors to market with new features.

But beyond just opportunity cost, there are a number of other factors at play that all too often get in the way of codebase upgrades, including: 

• Visibility: developers rarely have the time to keep up with dependency vulnerabilities, newly released versions, or other changes happening with their dependencies – they’re too busy coding against them. While others may have better visibility, they tend to get a siloed view, such as security tracking vulnerabilities, or compliance catching changes in licensing. 
• Time: any complex application will have dozens if not hundreds of dependencies, all of which represent a serious time commitment if they are to be kept up to date and non-vulnerable. Most developers have more than enough work on their hands just meeting their sprint deliverables.
• Complexity: sometimes dependency upgrades go smoothly. Sometimes they result in dependency hell that corrupts your environment and sends you down a rabbit hole of transitive dependency compatibility issues.

And of course, nobody wants to be the person responsible for breaking the build by inadvertently upgrading a library that introduces a bug or breaking change. 

How to Simplify Python Upgrades

The ActiveState Platform has been designed to address the time, complexity and visibility issues holding back the software industry from regularly updating their codebases. Sooner or later you’re going to have to bite the bullet anyway, but massive upgrades are almost always worse than incremental updates. The ActiveState Platform can help make regular dependency upgrades/remediation far less onerous than other systems.

Visibility Into Dependencies

The ActiveState Platform provides a central registry for all the dependencies across all your projects that every stakeholder can view and interact with:

• Security personnel can identify vulnerabilities at the language, OS and dependency/transitive dependency levels.
• Compliance personnel can identify open source licenses that may conflict with corporate guidelines.
• Developers can identify outdated dependencies, as well as how transitive dependencies shift when dependencies are upgraded. 

Minimizing Remediation Time

Vulnerability remediation is typically a significant time and resource investment involving investigation, patching/upgrading, rebuilding and redeploying. The ActiveState Platform can help provide a shortcut here by letting you: 

1. Select a non-vulnerable version of the affected dependency. Compatible dependencies/transient dependencies will automatically be chosen for you.
2. Automatically rebuilding your environment.  

This point-and-click process can save significant time and effort. See how it works in this 2 minute video. 

Eliminating Dependency Hell

When upgrading from an older version of Python to a newer one, dependencies will typically also need to be upgraded. For example, when upgrading from Python 3.7 to 3.10.8, the ActiveState Platform might generate the following solver error:

 

By simply setting the version of all top-level dependencies to “Auto,” the solver will determine the best upgrade path for your project, automatically selecting the versions of top-level dependencies, transitive dependencies and OS-level dependencies that work best together:

• Newer versions are highlighted in blue.
• Dependencies that are no longer required are highlighted in red.
• Newly required transitive dependencies are highlighted in green.

In this way, you can see at a glance all the changes that will be implemented BEFORE you update your runtime, ensuring everyone from Security to Compliance to the rest of your team is onboard with the changes.   

Conclusions

Never updating a codebase is a habit that needs to be done away with sooner rather than later. And if the software industry won’t do it themselves, there’s plenty of government legislation pending that will force them into it. 

It doesn’t need to be painful. Just remember that updating a codebase should never be a one-and-done affair. Rather, consistent, incremental changes applied regularly will ensure your application remains secure, performant and maintainable over time. As a best practice, 10-20% of every sprint should be dedicated to maintenance work. In this way, you can minimize risk by spreading changes out over several releases, which will make resolving any issues with the build that crop up much easier to deal with.

Read Similar Stories