The Security Shift: Why Python is Moving from Fix-It-Later to Secure-by-Design

In this conversation, Seth Larson, the Python Software Foundation’s Security Developer in Residence, explains that the Python ecosystem is undergoing a fundamental structural change. The rise of AI-driven vulnerability discovery has made the traditional patch-as-you-go model obsolete, forcing the community to adopt formal, high-volume security processes. The core idea is simple: the era of security by obscurity is over, and the new competitive advantage lies in radical transparency and standardized tooling. For developers, this shift is not just about avoiding hacks; it is about participating in a more mature, professionalized landscape where security is a measurable, credentialed contribution. Those who adopt these new standards now will stay ahead of the curve as the industry eventually mandates these practices for everyone.

The Hidden Cost of Fast Security

Most teams treat security as a reactive, piecemeal chore, fixing bugs only when they become problems. Larson argues this approach is no longer viable. The rise of Large Language Models (LLMs) has turned vulnerability discovery into a high-volume, automated game. When an LLM finds a flaw, that flaw is effectively public, regardless of whether a CVE has been issued.

> The ability for LLMs to discover vulnerabilities is real. I mean, the scale of it maybe is different than what is being talked about but it is real and it is more than what has been seen in the past.
>
> -- Seth Larson

The consequence is a massive surge in triage volume. Larson notes that the Python Security Response Team (PSRT) experienced a 3x to 4x increase in vulnerability reports compared to previous years. The system is responding by formalizing processes, moving from informal mailing lists to structured ticketing systems and bot-assisted contribution tracking. This shift creates a new middle ground for contributors: you no longer need to be a domain expert in CPython to be useful. By focusing on triage, testing, and remediation, newcomers can enter the ecosystem through security, bypassing the traditional, steep domain expert barrier.

Why Your Opaque Dependencies Are a Liability

A significant portion of Python’s security risk is hidden in plain sight. Many developers install wheels without realizing they are pulling in complex, compiled C libraries (like libjpeg or libpng inside Pillow) that are invisible to standard software composition tools.

> The software composition tools will not pick that up by default because it only sees a binary that is just opaque. And so it cannot necessarily pick up the fact that that is libjpeg.
>
> -- Seth Larson

This creates a blind spot where vulnerabilities in underlying C libraries remain unpatched because the Python-level scanner does not know they exist. The solution, formalized in PEP 770, is the adoption of Software Bill of Materials (SBOMs). By explicitly documenting these sub-dependencies, the ecosystem moves away from hoping the underlying stack is secure toward a verifiable, audit-ready supply chain. This requires effort now, such as manual documentation or adopting build tools like Cargo, but it creates a lasting moat of operational stability that most teams currently lack.

The 18-Month Payoff: Why Formalization Wins

Larson emphasizes that the most durable security improvements, like Trusted Publishing, succeed because they solve two problems at once: they increase security and decrease developer friction. By using OpenID Connect to link build environments (like GitHub Actions) directly to PyPI, developers eliminate the need for long-lived API tokens.

This is the unpopular but durable path. It requires setup time that feels like a delay in the moment, but it removes the entire category of stolen credential attacks. As Larson notes, the cross-pollination between language foundations, where security engineers from Python, Ruby, and Rust share intelligence, is creating a standardized blueprint for the entire industry. The competitive advantage here is delayed: teams that adopt these standards today are building a resilient foundation that will be standard practice in 18 months, while others will be scrambling to retrofit their CI/CD pipelines under pressure.

Key Action Items

• Audit your CI/CD pipeline immediately: If you are using GitHub Actions, implement zizmor. It is a specialized, low-effort tool that identifies common security misconfigurations in your workflow. (Immediate)
• Adopt Trusted Publishing: Transition your project deployment to use OpenID Connect (OIDC) instead of static API tokens. This removes the risk of credential leakage and simplifies your release process. (Over the next quarter)
• Implement SBOMs (PEP 770): Start documenting your sub-dependencies. If you are building with Rust-based tools, leverage their automatic SBOM generation. This creates visibility into the opaque binaries your project relies on. (12 to 18 months)
• Shift your Security Education budget: Stop viewing security training as a one-off event. Use employer-allocated continuing education time to learn how to apply security research to your specific domain (e.g., Django security, web-layer hardening). (Ongoing)
• Formalize your vulnerability response: If you maintain an open-source project, adopt the PSRT’s approach: use a public-facing ticketing system and clear, plaintext proof-of-concept requirements. This reduces the cognitive load on maintainers and creates a clearer path for contributors to help you. (Over the next 6 months)