For decades, software security has been treated much like green vegetables at the dinner table: universally acknowledged as vital for long-term health, yet consistently pushed to the edge of the plate. While developers and enterprises have long agreed on the theoretical importance of secure coding practices, security topics were historically scattered across general conference schedules as single-session outliers or specialized workshops. However, at PyCon US 2026, held in Long Beach, California, that paradigm underwent a fundamental shift.
In a landmark decision by conference organizers, software security was granted its own dedicated, day-long track. Placed directly alongside artificial intelligence—the conference’s only other dedicated special-interest track—the security track signaled a maturing ecosystem that can no longer treat safeguarding codebases as an afterthought. From the opening keynote to the final closing remarks, the assigned room remained packed to the back walls, reflecting an urgent, growing appetite among developers, maintainers, and researchers to confront the mounting complexities of modern software supply chains.
Setting the Stage: The State of Python Security Today
To take the temperature of the Python ecosystem, the track’s organizers—alongside industry and academic leaders—curated an arc of talks that mapped out the contemporary threat landscape. The sessions delved into sophisticated supply chain attacks, the mechanics of dependency cooldowns, the implementation of zero-trust architectures, the evolution of software bill of materials (SBOMs), and the controversial, forward-looking push to integrate Rust into CPython.
At the heart of these discussions was a unified, sobering consensus: software security is nowhere near being a "solved problem." Rather than signaling failure, however, speakers and attendees viewed this realization as a healthy and necessary awakening. The packed rooms demonstrated that the Python community is finally moving past complacency, actively seeking pragmatic tools and architectural changes to fortify the millions of systems relying on Python daily.
Anatomy of a Phishing Campaign: The Human and Systemic Cost
Opening the day’s agenda, Mike Fiedler, PyPI’s Safety and Security Engineer, delivered a stark reality check titled "Anatomy of a Phishing Campaign." Fiedler, one of the few individuals employed full-time to oversee the safety of packages installed from the Python Package Index (PyPI), used the session to dissect a novel and highly targeted attack vector targeting Python maintainers.
Unlike traditional, wide-net phishing campaigns that spray millions of generic emails in hopes of catching a careless user, this targeted campaign relied on open-source intelligence. Attackers harvested publicly available email addresses from GitHub profiles and package metadata. Crafting meticulously formatted emails that mirrored legitimate PyPI communications, the perpetrators directed maintainers to a sophisticated lookalike domain.
Crucially, the attackers registered a domain substituting an uppercase "I" with a lowercase "j"—PyPJ.org—a subtle typography trick nearly impossible to spot on mobile devices. Maintainers who entered their credentials were then subjected to adversary-in-the-middle proxies that captured not only usernames and passwords, but also time-based one-time passwords (TOTP) used for two-factor authentication (2FA).
While the vast majority of PyPI’s million-plus user accounts remained unaffected, four maintainers fell victim, resulting in the temporary compromise of a single sub-dependency: num-to-words, which sits upstream of Hugging Face’s widely utilized transformers library. Because the package was unpinned, downstream users risked automatically ingesting malicious updates. In response to the incident, PyPI rapidly instituted enhanced defenses, such as invalidating sessions when a user’s IP address changes abruptly following a TOTP login, while continuing to advocate for phishing-resistant hardware tokens like WebAuthn and passkeys.
Mitigating Risk Through Dependency Cooldowns
Building upon the conversation around supply chain vulnerabilities, the track explored the concept of dependency cooldowns—a mechanism designed to protect developers from zero-day malicious package uploads. Tools such as uv have begun implementing features that allow users to enforce a mandatory waiting period—ranging from three to seven days—before automatically adopting newly published package versions.
The philosophy behind dependency cooldowns is straightforward: malicious actors frequently publish compromised packages only to have them flagged and removed by automated security scanners or community watchdogs within hours. By introducing a delay, developers can bypass the immediate crosshairs of automated supply chain attacks. However, panel discussions highlighted the friction between security and developer experience. Cooldown windows can occasionally clash with urgent security patches, locking developers out of critical updates or creating confusing dependency resolution conflicts. Despite these growing pains, experts agree that safer defaults are essential for developers lacking dedicated corporate security teams.
Zero Trust and Regulatory Realities
Enterprise security requirements took center stage during the presentation "Zero Trust in 200 Milliseconds: Identity Per Transaction," led by Tristan and McKinnon. Exploring the rigorous intersection of federal compliance frameworks like FedRAMP and modern Python development, the talk challenged conventional approaches to static API keys and long-lived credentials.
The session demonstrated how organizations can architect applications to issue ephemeral, transaction-specific identity tokens rather than relying on persistent secrets that expand an application’s blast radius if leaked. By utilizing modern asynchronous frameworks and cloud-native integrations, developers can achieve zero-trust guarantees with negligible performance overhead. For enterprise developers navigating heavily regulated sectors, the talk provided a rare, practical blueprint for bridging federal compliance mandates with agile Python workflows.
The Cultural and Technical Debate Around Rust in CPython
Perhaps no topic generated as much fervent hallway discussion as Emma Smith’s presentation exploring the integration of Rust into CPython. As memory safety vulnerabilities continue to plague traditional C-based infrastructures, the software industry has increasingly turned to memory-safe languages like Rust.
However, introducing Rust into the core of CPython—historically the domain of C experts—presents profound cultural and technical hurdles. Smith’s talk navigated these sensitivities with nuance, emphasizing that any transition would require deliberate, incremental steps. As an initial proof of concept, developers have looked at modular components such as zlib, a compression library that frequently processes untrusted data and represents a classic vector for memory safety flaws.
While a full-scale rewrite of CPython remains a distant and debated horizon, the willingness to discuss memory-safe languages openly at PyCon US underscores the community’s dedication to foundational security hardening.
SBOMs and Runtime Visibility
Software Bill of Materials (SBOMs) formed another critical pillar of the security track. Sanchit Saye and Abhishek Reddy Pillai presented research on automating SBOM generation for Python builds, highlighting current discrepancies and inaccuracies in existing tooling. Their live demonstration illustrated how build-time analysis tools can more accurately capture network calls, compiler flags, and dependency trees to produce verifiable provenance records using standards like in-toto.
Complementing this, a session by Hala Ali and Andrew Case shifted the focus from build-time declarations to post-incident runtime visibility. By inspecting Python interpreter memory structures directly, their research showcased how security teams can generate accurate SBOMs of what is actively loaded in memory during execution. This capability allows organizations to determine whether vulnerable code paths are actually being executed, transforming theoretical CVE alerts into actionable intelligence.
GitHub Action Hardening and Vulnerability Tracking
Concluding the packed schedule, Andrew Nesbitt delivered a comprehensive overview of GitHub Actions security risks within Python ecosystems. Utilizing auditing tools like zismore, Nesbitt demonstrated how misconfigured workflows—particularly the hazardous use of the pull_request_target trigger—can expose maintainers to arbitrary code execution and cache poisoning attacks.
The day’s final presentations also addressed the growing friction within traditional vulnerability tracking systems. Shelby Cunningham and Madison Figuerely examined why conventional CVE tracking mechanisms struggle to properly categorize malware versus traditional software bugs, illustrating the urgent need for modernized threat intelligence infrastructure tailored to open source package registries.
Implications and Future Outlook
The overwhelming attendance at PyCon US 2026’s security track marks a watershed moment for the Python community. For years, open-source security has relied on the heroic, often underfunded efforts of a handful of maintainers and volunteers. The success of the dedicated security track proves that the developer base is ready to institutionalize security awareness from the ground up.
As discussions shift toward upcoming events like EuroPython, organizers are already planning expanded formats, interactive panels, and beginner-friendly security workshops for future conferences. Ultimately, the message resonating from Long Beach was clear: while software security will not be magically solved overnight, building a culture of shared responsibility, robust tooling, and proactive defense is the only way forward.
