How Python's Security Response Team Keeps Python Users Safe

This week the Python Software Foundation explained how they keep Python secure. A new blog post recognizes the volunteers and paid Python Software Foundation staff on the Python Security Response Team (PSRT), who "triage and coordinate vulnerability reports and remediations keeping all Python users safe." Just last year the PSRT published 16 vulnerability advisories for CPython and pip, the most in a single year to date! And the PSRT usually can't do this work alone, PSRT coordinators are encouraged to involve maintainers and experts on the projects and submodules. By involving the experts directly in the remediation process ensures fixes adhere to existing API conventions and threat-models, are maintainable long-term, and have minimal impact on existing use-cases. Sometimes the PSRT even coordinates with other open source projects to avoid catching the Python ecosystem off-guard by publishing a vulnerability advisory that affects multiple other projects. The most recent example of this is PyPI's ZIP archive differential attack mitigation.

This work deserves recognition and celebration just like contributions to source code and documentation. [Security Developer-in-Residence Seth Larson and PSF Infrastructure Engineer Jacob Coffee] are developing further improvements to workflows involving "GitHub Security Advisories" to record the reporter, coordinator, and remediation developers and reviewers to CVE and OSV records to properly thank everyone involved in the otherwise private contribution to open source projects.

Or just an ad to join a team of questionable value

[Mondragon]

There is no explanation of how they keep Python safe in that post (nor could there be). Pypi is a dumpster fire (not special, other language-specific repositories are also terrible from a security standpoint). At best they're keeping _python_ itself reasonably secure, but it does _nothing_ to keep _python users_ secure - python _users_ are using dozens to hundreds of community libraries that have no security oversight at all.

Re:

[93 Escort Wagon]

There are certainly worse Slashvertisements posted here all the time, and this one doesn't really bug me since it is at least on-topic with the (original, anyway) focus of this site. But, it is an ad. The actual title of TFA is

Join the Python Security Response Team!

Your comment is spot-on, though. Yes, there is clear value in working on bug- and security-fixes for any language, be it python, javascript, rust, php... But for most of those we're at the point where the language itself is a lesser issue. The

They aren't.

[Gravis Zero]

If you aren't following the Debian example of how to keep repos safe (and they are not) then you're just playing a game of cat and mouse with criminals. They only thing that has changed is they are making the cat and mouse game official.

I never understood, why memory safe languages do..

[Casandro]

...have such insecure repos. I mean you wipe out one class of security issues to allow for another much harder to contain class of security issues. Programming languages should have solid standard libraries and any kind of additional library should be installed either via the distribution, where there are minimal checks, or manually, where it hurts.

Weakest link is the hundreds of packages per app

[will4]

No one wants to take on the largest vector which is the packages and the weakest link in the chain.

This is the same issue across technology stacks, there are thousands of highly used packages and every one of them adds a small security risk.

If the risk is small, even 0.01% per package, you get a ~10% risk if there are 1000 packages used.

A 0.05% risk per package needs ~200 packages to get a 10% risk.

0.10% risk per package needs ~100 packages to get a 10% risk.