Our cybersecurity team expects us to upgrade to the newest Python release as soon as it becomes available. The concern is that libraries and their dependencies may not support the new version yet, and upgrading can break projects until everything has been tested and updated. We mainly use Python versions that are still within their support period and normally upgrade when there is a practical need, avoiding dependencies that require obsolete versions. However, IT now has a scheduled process that removes older Python installations automatically, forcing us to update all of our projects and virtual environments. Is blindly requiring the newest Python release a reasonable security policy, or would it be better to stay on a supported release branch and apply security patches while validating major upgrades?
3 Answers
The best answer is a risk-based upgrade process rather than a blanket “latest only” rule. Pin Python and dependency versions with lockfiles, maintain reproducible environments such as containers or devcontainers, and use automated vulnerability and dependency scanning. Apply urgent security fixes quickly, but give ordinary releases a short validation period. CI should run the full test suite against proposed upgrades before anything reaches production.
Ask the security team to document the actual threat model and the exception process. If they require every new Python release immediately, they also need to account for the engineering time required to test dozens of applications and resolve library incompatibilities. Track the cost, failed tests, and business impact, then bring engineering, security, and management together to agree on a support matrix and upgrade deadlines. A policy that breaks production without providing remediation time is creating operational risk in the name of reducing security risk.
That is the frustrating part: the scheduled cleanup removes older Python installations automatically, so the team has to upgrade even when a project is still supported and its dependencies are not ready.
Security should generally require a supported and patched Python release, not necessarily the newest major or minor version on the day it ships. Python’s maintenance releases contain bug and security fixes, while moving from one feature release to another can expose compatibility problems in libraries. A reasonable policy would define an approved support window, such as the latest patch release of one of the supported branches, with a planned migration before end of life.
Exactly. A properly patched older supported branch can be safer and much more stable than a brand-new release that the project’s dependencies have not caught up with yet.
Tools such as Dependabot or an internal package mirror can help identify vulnerable dependencies and prepare upgrade changes, but every update still needs testing. Automatically deleting interpreters from machines is not a substitute for a migration plan.