This week the Python core team shipped Python 3.9.2 and 3.8.8, both classified as security releases. While point releases rarely make headlines, these two address a handful of CVEs that are worth paying attention to — particularly if you’re running Python in production, which, let’s be honest, most of us are at this point.
The timing is notable. We’re still processing the implications of the SolarWinds supply chain attack, congressional hearings wrapped up just yesterday, and the entire industry is looking at its dependency chains with fresh eyes. Python, as the backbone of everything from machine learning pipelines to infrastructure automation, sits squarely in the crosshairs.
What Got Fixed#
The most significant fix addresses CVE-2021-3177, a buffer overflow in the ctypes module’s PyCArg_repr function. This is the kind of vulnerability that doesn’t sound exciting until you realize how many C extension bindings use ctypes under the hood. A crafted floating-point value could trigger a stack buffer overflow — classic C memory safety issue bleeding through Python’s abstraction layer.
There’s also a fix for urllib.parse that addresses potential web cache poisoning attacks, and several updates to the bundled pip and setuptools versions. None of these are “drop everything” emergencies in isolation, but taken together, they paint a picture of a project that’s taking security seriously.
What I find encouraging is the cadence. Python 3.9.1 came out in December, and here we are in February with 3.9.2. The team is shipping security fixes quickly, and the release notes are thorough. Compare this to how Python security updates worked even five years ago, and the improvement is stark.
The Supply Chain Angle#
I’ve been doing this long enough to remember when nobody thought twice about pip install whatever on a production machine. Those days are over, or at least they should be. The Python Packaging Authority (PyPA) has been making steady progress on improving the security of the packaging ecosystem — hash checking, pip’s dependency resolver rewrite (which shipped in pip 20.3), and ongoing work on PEP 458 for TUF integration with PyPI.
But there’s still a gap. Most teams I work with have decent CI/CD pipelines, but their Python dependency management is an afterthought. requirements.txt with unpinned versions, no hash verification, no private index for internal packages. After SolarWinds, and especially after the dependency confusion research that Alex Birsan published earlier this month, this feels increasingly reckless.
If you haven’t already, now is a good time to:
- Pin your dependencies with exact versions
- Use
pip’s--require-hashesflag in production builds - Set up a private package index (even a simple one like devpi) to control what gets installed
- Run Safety or pip-audit in your CI pipeline
Python’s Position in 2021#
Looking at the broader picture, Python is in an interesting position right now. It topped the TIOBE index again in February, which is one of those metrics that means both everything and nothing. More meaningfully, the ecosystem is maturing in ways that matter for production use.
Type hints continue to gain adoption. With Python 3.9’s dict and list being usable directly as generic types (no more from typing import Dict, List), the ergonomics keep improving. I’ve been gradually adding type annotations to a large codebase at work, and the combination of mypy and a well-typed codebase genuinely catches bugs. Not hypothetical bugs — real ones that would have shipped.
The performance story is also evolving. CPython’s “faster CPython” project led by Mark Shannon (and now backed by Microsoft, after Guido van Rossum joined them) is targeting significant speedups for 3.11. That’s still a ways off, but the commitment is there.
And then there’s the data science and ML ecosystem, which continues to be Python’s killer app. With frameworks like FastAPI gaining traction for serving ML models, and tools like Poetry and Pipenv improving dependency management, the gap between “Python for prototyping” and “Python for production” keeps narrowing.
My Take#
I’ve been writing Python since the 2.3 days, and the language’s evolution has been remarkable. Not because of flashy features — Python has always been conservative about syntax changes (the walrus operator debate proved that) — but because the ecosystem around it has professionalized.
These security releases are a small but important example. The Python core team is responding to vulnerabilities quickly, the CVE process is working, and the community is taking supply chain security more seriously. After watching the Perl ecosystem slowly fade partly due to neglect of exactly these kinds of concerns, I don’t take it for granted.
If you’re running Python 3.8 or 3.9 in production, update. If you’re still on 3.6 or 3.7, start planning your migration — 3.6 reached end-of-life in December 2020, and 3.7 is next. And regardless of your version, take another look at your dependency management practices. The threat landscape has changed, and our tooling needs to keep up.