The Python Software Foundation Explained: Governance, PyPI, Security

The Python Software Foundation (PSF) is a US non-profit membership corporation, organised under Delaware law, that holds the intellectual property rights to most Python releases, protects the Python and PyPI trademarks, runs python.org and the Python Package Index (PyPI), and pays staff who work on CPython, packaging and security. It does not decide what goes into the language. That job belongs to the five person Python Steering Council, which the core developers elect under PEP 13.

This guide goes one level deeper than our posts on open source foundation governance models and how the Linux Foundation and Apache approach governance, and it is a sister piece to our explainer on the Eclipse Foundation. We read the PSF's own pages and bylaws, the governance PEPs (13, 8016 and 811), the PSRT process in the CPython developer guide, PyPI's security policy and documentation, PEP 740, and the PSF and PyPI blog posts that announced each change. Every rule, role and date below comes from those sources unless we say otherwise.

Key takeaways

• The PSF is a Delaware non-profit membership corporation. Voting members (Supporting, Contributing and Fellow members) elect a Board of Directors in staggered cohorts; the board hires an Executive Director, who leads a paid staff. Directors are not paid for serving as directors.
• The PSF does not own technical direction. Under PEP 13, the core team elects a five person Steering Council after each feature release. The council can accept or reject PEPs, delegate decisions and work with the PSF to manage project assets. No more than two council members may work for the same employer.
• The PSF stewards Python's intellectual property. It establishes the PSF licences, holds rights to most Python releases and protects trademarks including "Python", "PyPI", "Python Package Index" and their logos.
• PyPI is operated by the PSF with a small paid team and volunteer administrators; the PSF says it now serves two to three billion requests a day.
• Two security roles exist because of a grant: the Security Developer in Residence (first hired in June 2023) and the PyPI Safety and Security Engineer, both funded by the OpenSSF Alpha-Omega project.
• The Python Security Response Team (PSRT) handles vulnerability reports for CPython and pip. Under PEP 811, each report gets a Coordinator who aims to reach a finished state within 90 days, scores severity with CVSS and writes the advisory that the PSF CVE Numbering Authority (authorised in August 2023) turns into a CVE record. The PSRT published 16 advisories for CPython and pip in 2025, its highest yearly count.
• PyPI security features shipped since 2023: Trusted Publishing (April 2023), mandatory two factor authentication for every account (1 January 2024), PEP 740 digital attestations (November 2024) and project quarantine (2024).
• On the EU Cyber Resilience Act, the PSF welcomed the "open source software steward" concept in the final text and co-started a cross foundation standards initiative in April 2024.

What is the Python Software Foundation?

The PSF describes itself as "the organization behind the open source Python programming language," devoted to creating the conditions for Python and its community to grow. Its about page groups the work into three areas.

Infrastructure. The PSF distributes Python free of charge. It establishes the PSF licences, holds intellectual property rights to most Python releases and protects Python related trademarks. It also puts resources behind improvements to the Python codebase and new releases.

Community. The PSF runs PyCon US, which it calls the longest running annual Python event. It awards grants; the about page says that in 2024 it awarded $655,000 to 257 groups or individuals in 61 countries. It establishes, maintains and enforces the Python Code of Conduct, and it fiscally sponsors 20 Python related community groups, conferences and projects, which gives them a legal and financial home without each forming its own non-profit.

Investing in Python and tools. The PSF hosts PyPI, employs a Packaging Project Manager, and employs a full time CPython Developer in Residence who processes CPython pull requests and works on structural improvements to the codebase.

When was the PSF founded, and why?

The PSF was formed in 2001. The history section of the official Python documentation explains why. Guido van Rossum created Python in the early 1990s at Stichting Mathematisch Centrum (CWI) in the Netherlands. In 1995 he continued the work at the Corporation for National Research Initiatives (CNRI) in Virginia. In May 2000 he and the core team moved to BeOpen.com to form the BeOpen PythonLabs team, and in October 2000 the team moved again, to Digital Creations (later Zope Corporation). Then, in the documentation's words, "In 2001, the Python Software Foundation ... was formed, a non-profit organization created specifically to own Python-related Intellectual Property."

Python's rights had passed through four organisations in about ten years. A neutral non-profit that owned the code, licence and name meant the language no longer depended on whichever company employed its core developers.

What kind of organisation is it legally?

The bylaws describe a corporation with a registered office in the State of Delaware, operating under the General Corporation Law of Delaware, with members, a Board of Directors and officers. Its members have defined voting rights, which makes it a membership organisation rather than a board only charity or a trade association of companies. That detail shapes everything else: individuals, not member companies, elect the PSF board.

How is the PSF governed?

Three layers make decisions: the members, the board and the staff. A fourth group, the Python core team, governs the language itself and is covered in the next section.

Members

The bylaws define four membership classes: Basic Members, Supporting Members, Contributing Members and Fellows. (A legacy class of Managing Members from older bylaws was folded into the new structure.) The membership page explains how you qualify.

Voting is not automatic even in the voting classes. The bylaws say members of any class with voting rights must affirm each year, in writing, that they intend to vote. That annual affirmation keeps the electorate to people who are actually engaged.

How elections work

The bylaws set the mechanics. Directors are elected by a plurality of the votes cast. For electronic votes, quorum is reached as soon as one third of the members entitled to vote have voted; if the voting period ends before quorum, the vote is declared invalid. Special meetings can be called by the board or by members holding at least ten percent of the votes.

The board began with eleven directors. The bylaws let the voting members change that number at an annual meeting, but only to another odd number greater than three. After the 2017 election, directors were split into three cohorts with initial terms of three, two and one years, which created staggered terms: each year only part of the board stands for election. Board members are not compensated for their duties as directors, although the bylaws allow a director to be paid for separate work as an officer, employee or contractor.

Board and officers

The board page lists the directors and the officers chosen each year. The officer roles it shows are President and Chair, Vice Chair (with a Vice Chair Elect), Secretary, Treasurer and PyCon US Chair. The Executive Director has served as Secretary in recent years. The board sets strategy, approves the budget, adopts policies such as the trademark usage policy and the Code of Conduct, and hires the Executive Director.

Staff

The staff page lists the people the PSF employs. As of October 2026 that includes an Executive Director (Deb Nicholson, who joined in April 2022), a Deputy Executive Director for fundraising, PyCon US and events staff, finance staff, a Community Communications Manager, a Director of Engineering with infrastructure engineers, a PyPI Support Specialist (a role first filled in 2024, according to that year's annual impact report), the Python Security Developer in Residence (Seth Larson) and the PyPI Safety and Security Engineer (Mike Fiedler).

The split between board, staff and the language's own governance matters to anyone mapping accountability. If you want to know who decided to make two factor authentication mandatory on PyPI, the answer runs through PSF staff and the PyPI administrators. If you want to know who decides whether a new syntax feature belongs in the next Python release, the answer is the Steering Council and the PEP process, not the PSF board.

How does the PSF relate to the Steering Council and the core developers?

From BDFL to Steering Council

For most of Python's history Guido van Rossum held the informal title of Benevolent Dictator for Life (BDFL) and made the final call on language changes. In July 2018 he stepped back from that role and left the core developers to decide how to govern themselves. Several competing models were written up as PEPs in the 8000 series. PEP 8016, "The Steering Council Model," won: its header records that it "was accepted by a core developer vote described in PEP 8001 on Monday, December 17, 2018." Its text became PEP 13, "Python Language Governance," which is the living document today. We compare the BDFL pattern with other models in our post on BDFL, meritocracy and liberal contribution governance.

What PEP 13 says about the core team

PEP 13 defines a core team whose members have commit rights and authority over the Python project infrastructure, and who take part in formal votes. Membership is "granted by receiving at least two-thirds positive votes in a core team vote that is open for one week and is not vetoed by the steering council." Removing a core team member is one of the few things the council can do only with a supermajority: PEP 13 requires at least two thirds of the council, and spells out that "with 5 members voting, this means that a 3:2 vote is insufficient; 4:1 in favor is the minimum." That power cannot be delegated.

What PEP 13 says about the Steering Council

The council has five members and "broad authority to make decisions about the project." PEP 13 lists examples of what it can do, including:

• accept or reject PEPs;
• work with the PSF to manage any project assets;
• delegate parts of its authority to other subcommittees or processes (this is how a PEP delegate gets the final word on, say, a packaging standard);
• act as a court of final appeal where other processes fail, a phrase carried over from PEP 8016.

PEP 8016 also notes that to use its powers "the council votes," and every member must either vote or explicitly abstain, with members who have a conflict of interest expected to abstain.

Three rules keep the council accountable:

• Elections after every feature release. "A new council is elected after each feature release." In practice that means a yearly election, matched to Python's annual release cycle. Candidates must be nominated by a core team member; self nomination is allowed. PEP 13 describes a voting phase in which each core team member can assign zero to five stars to each candidate. Voting is anonymous and is run by a returns officer nominated by the outgoing council; for the very first election in 2019, PEP 13 had the PSF Executive Director nominate the returns officer. That was one of the few formal touch points between the PSF and language governance.
• An employer cap. "At most 2 members of the council can work for any single employer." If an election produces more, the lowest ranked candidate from that employer is disqualified; if a mid term job change breaks the rule, members must resign until it is restored.
• No confidence votes. Any core team member can call one publicly; if another core team member seconds it within a week, a two week vote follows. It succeeds if at least two thirds of voters express a lack of confidence, and it can target one council member or the whole council.

Changing PEP 13 itself needs at least a two thirds majority of votes cast in a core team vote open for two weeks.

Who decides what

Note the packaging rows. PyPI the service is run by the PSF, but interoperable standards such as the attestation format are PEPs accepted under the Steering Council's process. PEP 740, for example, names Donald Stufft as PEP delegate and was resolved as Final on 17 July 2024.

What does the PSF own and run?

The Python and PyPI trademarks

The PSF trademark usage policy says "Python" is a registered trademark of the PSF, and so are the Python logos. The PyPI site footer adds that "PyPI", "Python Package Index" and the blocks logos are registered trademarks of the PSF. The policy wants the word mark and logos used freely to refer to the language, but it asks for prior approval for some uses, both commercial and non-commercial, and it says any commercial use of PSF trademarks in product or company names needs approval. A modified logo for any commercial purpose also needs approval. The policy suggests that organisations using the Python name or logo consider donating to the PSF.

For security teams the lesson is simple: a package, site or account using the Python or PyPI name and logo is not thereby an official PSF property.

python.org and the release files

The PSF runs python.org, which publishes the CPython source releases and official installers. Since the Security Developer in Residence role began, the release pages have gained two things worth knowing about.

• Sigstore signatures. Python releases include Sigstore signatures from the Release Managers. The developer in residence's 2023 Q3 report describes auditing existing signatures, fixing discrepancies between documented identities and what was published, and adding safeguards to release tooling so signatures verify as documented.
• SBOMs. Starting with CPython 3.12.2 in February 2024, CPython source releases come with SPDX Software Bill of Materials documents, in an "SBOM" column of each release page's Files table. The PSF said the first pass was curated by hand for accuracy, then automated to track changes. The CPython developer guide now has an SBOM page next to its PSRT page.

The licences

The licence page in the Python documentation lists the agreements that cover Python today: the PSF License Agreement (version 2), plus the BeOpen.com, CNRI and CWI agreements that cover older code, reflecting the ownership chain above. Code examples in the Python documentation are separately offered under a Zero-Clause BSD licence. The same page lists the licences and acknowledgements for third party code incorporated in CPython, such as the Mersenne Twister and parts of the socket and XML modules. If you build a product on CPython, that page is part of your licence review, not just the top level PSF licence.

PyPI

PyPI is the default index for pip and every mainstream Python installer, and the PSF owns and runs it. It is the single most important thing the PSF operates from a supply chain point of view, and it gets its own section below.

The PSF also handles the human side of names on PyPI. PEP 541 governs package name retention, abandoned projects and transfers; we walk through it in how to claim an abandoned PyPI name under PEP 541.

How is PyPI operated and funded?

Scale

In an October 2025 post, the PSF said PyPI's usage has grown "effectively exponential[ly]" since 2018, with daily requests rising from the millions to "2-3 billion per day at present." The same post says the PSF's investment began with a full time Director of Infrastructure hired in June 2018.

Who runs it

The October 2025 post names the paid staff who support PyPI, including the PyPI Support Specialist and the PyPI Safety and Security Engineer, alongside infrastructure staff. Volunteer PyPI administrators and maintainers of Warehouse (the open source application that runs PyPI) do the rest. The post is direct about the largest cost: "The largest cost for the PSF is staffing."

Who pays

The post says the PyPI Safety and Security Engineer role is funded by a grant from the Linux Foundation's Alpha-Omega project, and that the other PyPI roles are paid from the PSF's general fund, which comes from sponsorships and individual contributions. Hosting, CDN, monitoring and error reporting come largely in kind from long term partners. The post names several, and notes that in 2024 the PSF signed a five year agreement with its CDN provider under that provider's open source program, a different kind of commitment from annual renewals.

In September 2025 the PSF co-signed the OpenSSF joint statement "Open Infrastructure is Not Free" as PyPI's steward. Its follow up agreed with the letter that this is "not (yet) a crisis" but called it "a critical inflection point."

What has the PSF staffed for security?

Security Developer in Residence. The PSF announced in January 2023 that it was hiring, and on 22 June 2023 it named Seth Larson as its "first ever Security Developer-in-Residence," noting that the role "would not be possible without funding from the OpenSSF Alpha-Omega Project." In August 2024 Alpha-Omega extended the role through the end of 2024, a six month extension meant to align renewals with the calendar year. The staff page says the role works "on broadly improving the security posture of the Python ecosystem across many projects including CPython and PyPI." Work the PSF has attributed to the role includes:

• getting the PSF authorised as a CVE Numbering Authority (August 2023);
• reviving the security-announce@python.org advisory list;
• migrating historical Python vulnerabilities to the Open Source Vulnerability (OSV) format so they are indexed in the global OSV database;
• auditing and fixing Release Manager Sigstore signatures;
• publishing SBOMs for CPython releases (February 2024);
• writing PEP 811, which gave the PSRT a public governance document (resolved December 2025).

PyPI Safety and Security Engineer. Mike Fiedler was the first person in this role, which is also funded by Alpha-Omega. The role covers PyPI malware response and account safety, and its holder wrote the PyPI blog post that introduced project quarantine. When the quarantine post was written, it noted that PyPI's full time security staff numbered exactly one.

CPython Developer in Residence. Not a security title, but relevant. The developer in residence reviews and lands CPython pull requests, including security fixes, and helps with release work.

At PyCon US 2026 the two Alpha-Omega funded staff gave a joint update. The PSF's write up summarises 2026 as "the year of more": more packages published to PyPI than ever, but also more malware and, specifically, watering hole attacks targeting PyPI users. A maintainer session at the same event reported a sharp rise in vulnerability reports, many generated with large language models.

How does the Python Security Response Team handle reports?

Scope

The python.org security page says the PSRT "does triage on all reported vulnerabilities" for two projects:

• CPython, for stable and end of life versions on supported platforms, as published at python.org/downloads;
• pip, for versions published on PyPI.

The PSRT does not accept reports that only affect pre-release versions; those are "in-development" and should be raised as public issues. It does not accept reports about third party redistributions of Python or pip, which go to that distributor's security contact. And the PSF "does not run any bug bounty programs," which the page explains by noting the PSF is a non-profit that depends on donations.

Third party packages on PyPI are outside PSRT scope. A flaw in a popular library such as Pillow is handled by that project's own maintainers under its own policy; our Pillow security guide shows what that looks like for one widely used package.

How to report

Email security at python dot org. Only PSRT members see that list. Under PEP 811, reporters are increasingly directed to file through the GitHub Security Advisory (GHSA) form of the affected repository instead; the email list stays open as a fall back and as the hotline for python.org and other Python web properties.

The process, step by step

PEP 811 (an Active process PEP, created 22 October 2025 and resolved 4 December 2025) and the CPython developer guide define the inside of the process. Combined with the public steps on python.org, it runs like this:

Three details stand out.

A 90 day clock. Each report should reach a finished state within 90 days of receipt. PEP 811 explains why: many reporting organisations already use a 90 day timeline and will publish even without a fix, so aligning with it keeps reports from getting stuck or going public unpatched.

Per report access. Before PEP 811, patches were developed in a private mirror repository to which every collaborator had access, so all collaborators saw all reports. GHSA lets the PSRT add people per report, which limits who sees each embargoed issue and makes it easier to bring in the right core developer or the reporter.

CVSS scoring. The developer guide specifies CVSS version 4 for severity. PEP 811 says "CVSS" without a version.

Who is on the PSRT

The PSRT is small by design. Membership is by nomination: an existing member nominates, and the nomination passes with at least two thirds positive votes in a vote open for one week that the Steering Council does not veto. PEP 811 says new members are expected to come from core developers, triagers or PSF staff, and that its cleanup would cut membership from about 30 to about 15. Release Managers must be PSRT members during their term. Steering Council members and release team experts may join and are exempt from inactivity removal. At least two members serve as admins, designated by the Steering Council; they triage the mailing list and manage the GitHub team, mailing list and chat channel so all three match the canonical member list.

In February 2026 the PSF announced that an infrastructure engineer had joined as the first new member who was not a Release Manager since 2023, and reported that the PSRT published 16 advisories for CPython and pip in 2025, "the most in a single year to date."

How CPython publishes advisories as a CNA

The PSF announced in its 2023 Q3 security report that it had been authorised as a CVE Numbering Authority in late August 2023, with a scope covering Python and pip. Before that, CVE IDs for Python issues had to be requested from another CNA. Being the CNA lets the PSF assign IDs itself and publish richer records, including remediation information.

Advisories reach the public in two machine and human readable places:

• the security-announce@python.org mailing list, which has a public archive of historical advisories;
• an advisory database on GitHub in OSV format, which tools can consume directly.

To update or dispute a CVE record issued by the PSF CNA, email cna at python dot org, after checking the record really came from the PSF CNA and not another one.

For third party packages on PyPI, advisories come from each project's maintainers and the community maintained PyPA advisory database; see our guide to following Python package advisories with the PyPA advisory database.

How do you report a malicious or vulnerable package on PyPI?

PyPI's security policy is separate from the PSRT's. It distinguishes three cases.

• A malicious project hosted on PyPI. Log in to PyPI, go to the project page, and at the top of the Security tab choose "Report project as malware." The form asks for the project URL, an explanation of what makes it a security issue, and a link to the problematic lines through inspector.pypi.io. The policy lists typosquatting, dependency confusion, data exfiltration, obfuscation and command and control as examples of valid malware reports.
• A security issue in PyPI itself. Email security@pypi.org with as much detail as possible, including steps to reproduce. You should receive an acknowledgment within 48 hours.
• A vulnerability in a legitimate package. Contact that package's maintainers through its own security policy. PyPI hosts the files; it is not the vendor of the code.

The policy asks reporters not to raise PyPI security issues in any public forum, including the GitHub issue tracker, chat channels and mailing lists. The page says the policy was last updated in September 2026.

Dependency confusion is one of the listed abuse patterns, and the packaging community's long running attempt to address it at the standards level is covered in what happened to PEP 708.

What PyPI security features has the PSF shipped?

Timeline

Mandatory two factor authentication

The May 2023 announcement framed 2FA around a promise PyPI makes: when you download something, "only the people associated with that project are going to be able to upload, delete, or otherwise modify a project." That promise is only as strong as each maintainer's account. PyPI had already blocked compromised passwords, offered strong 2FA and required it for the most downloaded projects. The May 2023 post extended the requirement to every account that publishes, by the end of 2023.

On 1 January 2024 PyPI published "Two-factor authentication is required for all users." Users without 2FA must enable it before performing any management actions. The supported methods are TOTP authenticator apps and WebAuthn security keys, or both. Uploads use API tokens or Trusted Publishing rather than a password.

Trusted Publishing

PyPI's docs define Trusted Publishing as "our term for using the OpenID Connect (OIDC) standard to exchange short-lived identity tokens between a trusted third-party service and PyPI." The flow works like this:

1. A project owner configures a trusted publisher on PyPI, for example a specific GitHub repository and workflow file, optionally with a deployment environment.
2. When that workflow runs, the CI service issues it an OIDC token describing exactly which repository, workflow and trigger it is.
3. The workflow presents the token to PyPI. PyPI matches it against the trusted publisher configurations. If a project trusts that identity, PyPI mints an API token for that project.
4. The minted token "behaves exactly like a normal project-scoped API token, except that it's only valid for 15 minutes from time of creation."

The docs list GitHub Actions, GitLab CI/CD and Google Cloud among the supported providers. You can also create a project with a trusted publisher before its first upload, so a project never needs a long lived token at all.

The gain is mostly about secrets: no standing token sits in CI to leak, and the one that exists is scoped to one project and expires in minutes.

Attestations (PEP 740)

PEP 740 defines how an index can accept, store and serve digital attestations for each file. PyPI's attestation docs say the signatures "bind each release distribution (such as an individual sdist or wheel) to a strong cryptographic digest of its contents," so that both PyPI and downstream users can check that a file was attested by a particular identity, such as a GitHub Actions workflow. PyPI uses the in-toto Attestation Framework. It currently accepts up to two attestations per file, one for each allowed predicate: a publish attestation (proof that the file was published through a specific Trusted Publisher) and SLSA provenance.

The November 2024 announcement said generation and publication "happens by default" for projects that publish with the official PyPA publish action through Trusted Publishing, and that more than 20,000 attestations had already been published. PyPI exposes them in two ways: an Integrity API that returns all attestations for a file, and a provenance URL on each file in the JSON simple API. The PyPI post also explained why it chose identity based signing over long lived keys: attestations are "signed by an identity, not a key pair," which removes the failure mode of a maintainer losing or leaking a private key.

PEP 740 itself is careful about scope. It "does not make a policy recommendation around mandatory digital attestations on release uploads or their subsequent verification by installing clients like pip." Verification is up to you.

Project quarantine

Before quarantine, PyPI administrators had one main tool for a malicious project: complete removal from the PyPI database, which the quarantine post calls disruptive and "pretty much irrevocable." Quarantine adds a middle state. While a project is quarantined, according to the post:

• it is not installable, because it is hidden from the simple index;
• its owners cannot modify it;
• its state is visible to the owners, security researchers and administrators;
• an administrator can revert it to restore visibility, or delete it.

Quarantine shortens the time a reported project stays installable, while leaving room to correct a mistaken report. The post also explains why it is not the same as yanking: a yanked release can still be installed by clients that ask for it, and yanking applies to a release rather than a whole project.

What does the PSF say about the EU Cyber Resilience Act?

The PSF's CRA position is on the record in three posts.

April 2023: concern. The PSF argued that the draft risked leaving individual and under-resourced developers "in a legally murky position when contributing to public repositories like the Python Package Index," and stressed the role that vendor neutral non-profits and public software repositories play in modern software. Its January 2024 follow up summarised the request it had made: language exempting public software repositories offered as a public good, and the hobbyists and individuals who publish to them.

12 January 2024: relief, with caveats. After the final text was settled in December 2023, the PSF wrote that the CRA "passes with wins for open source." It quoted the new definition of an open source software steward ("any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities") and the recital saying that providing free and open source software that is not monetised by its manufacturers is not a commercial activity. It said the steward concept is "a brand new idea in European law" that it would keep watching, and flagged the Product Liability Directive as the next law to follow.

April 2024: standards work. The PSF announced it was co-starting the Open Initiative for Cybersecurity Standards with the Apache Software Foundation, the Eclipse Foundation, other code hosting foundations, SMEs, industry and researchers, aiming at "common specifications for secure open source development based on existing open source best practices" and at meeting expectations of the open source steward role.

For a company that ships Python in a product sold in the EU, the conclusion matches the one in our Eclipse post. You are the manufacturer. The PSF's steward role covers the projects it supports; it does not transfer your due diligence on CPython, pip or any wheel from PyPI to the foundation.

How does the PSF compare with other foundations?

The table compares legal form, who controls technical direction and how security is staffed. It describes structure only; it is not a ranking.

Two structural points stand out. The PSF operates one of the largest public package registries itself, which puts abuse response and account security inside the foundation. And the PSF board does not appoint Python's technical leaders; the Steering Council answers to the core team.

Step by step: using what the PSF and PyPI publish in your own pipeline

None of the steps below needs a commercial tool. They use public PSF and PyPI interfaces plus pip.

Step 1. Know which CPython you run

python3 -VV
python3 -c "import sys, platform; print(sys.version_info, platform.python_implementation())"

Compare the version with the status of its branch on python.org. Once a branch reaches end of life, it no longer receives security releases, and the PSRT's scope is limited to supported platforms.

Step 2. Subscribe to CPython and pip advisories

Subscribe to security-announce@python.org for human readable advisories. For automation, consume the PSF advisory database in OSV format, which covers CPython and pip, or query the public OSV database, where the historical records are indexed.

# Query OSV for a pip version (public API, no key required)
curl -s https://api.osv.dev/v1/query \
  -d '{"package": {"name": "pip", "ecosystem": "PyPI"}, "version": "23.0"}' \
  | python3 -m json.tool | head -40

Step 3. Verify the CPython source you build from

Release Managers sign CPython artifacts with Sigstore. The python.org release pages publish a .sigstore bundle next to each file, and the expected signing identity for each release series is documented on python.org's Sigstore page.

python3 -m pip install sigstore
python3 -m sigstore verify identity \
  --bundle Python-3.14.0.tgz.sigstore \
  --cert-identity RELEASE_MANAGER_IDENTITY_FROM_PYTHON_ORG \
  --cert-oidc-issuer ISSUER_FROM_PYTHON_ORG \
  Python-3.14.0.tgz

Replace the two placeholders with the values python.org lists for that release series. If verification fails, do not build from the file.

Step 4. Check provenance for a package you depend on

The JSON simple API now includes a provenance URL for files that have attestations:

curl -s -H "Accept: application/vnd.pypi.simple.v1+json" \
  https://pypi.org/simple/sampleproject/ \
  | python3 -c "import json,sys; d=json.load(sys.stdin); [print(f['filename'], f.get('provenance')) for f in d['files'][-4:]]"

A None means no attestation was published for that file. A URL points at the Integrity API, which returns the attestations and the Trusted Publisher identity:

curl -s https://pypi.org/integrity/sampleproject/4.0.0/sampleproject-4.0.0.tar.gz/provenance \
  | python3 -m json.tool | head -40

Check that the publisher repository and workflow in the response are the ones you expect for that project. A provenance record pointing at an unfamiliar repository is a reason to stop and investigate.

Step 5. Publish your own packages with Trusted Publishing

Configure a trusted publisher in the project's PyPI settings, then use a workflow like this. The id-token: write permission lets the job request the OIDC token; attestations are generated by default with the official publish action.

name: release
on:
  release:
    types: [published]
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.13"
      - run: python -m pip install build && python -m build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
  publish:
    needs: build
    runs-on: ubuntu-latest
    environment: pypi
    permissions:
      id-token: write
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - uses: pypa/gh-action-pypi-publish@release/v1

Splitting build and publish keeps the short lived publishing permission away from the build step. After the first trusted release, revoke any old API tokens for the project.

Step 6. Pin and hash what you install

python3 -m pip install pip-tools
pip-compile --generate-hashes -o requirements.txt requirements.in
python3 -m pip install --require-hashes -r requirements.txt

Hashes make sure the file you install is byte for byte the one you reviewed. They do not tell you whether that file is safe, which is why steps 2 and 4 still matter.

Common mistakes

• Treating the PSF as the vendor of every package on PyPI. The PSF operates the index and responds to abuse. Each project's maintainers publish and support their own code.
• Sending a PyPI malware report to security@python.org. That address is for CPython, pip and Python web properties. Malicious projects go through the Security tab on the project page; PyPI platform bugs go to security@pypi.org.
• Confusing the PSF board with the Steering Council. The board runs the non-profit. The council, elected by core developers, decides the language. Lobbying the wrong body wastes time.
• Assuming an attestation means a package is safe. An attestation proves which workflow built and published a file. A malicious commit in the right repository still produces a valid attestation.
• Keeping long lived API tokens in CI after moving to Trusted Publishing. The point of Trusted Publishing is to remove standing secrets. Revoke the old tokens.
• Assuming yanked means removed. A yanked release can still be installed by a client that pins it. Quarantine and removal are the administrator actions that stop installs.
• Reporting a distribution's Python package to the PSRT. Third party redistributions, including Linux distribution builds, have their own security contacts.
• Assuming the CRA steward role covers your product. If you sell a product with Python inside it in the EU, the manufacturer obligations are yours.

FAQ

Who owns Python?

The PSF holds the intellectual property rights to most Python releases and the Python trademarks. The language itself is steered by the Steering Council and core team under PEP 13.

Is the Python Software Foundation the same as the Python Steering Council?

No. The PSF is a non-profit with members, a board and staff. The Steering Council is five people elected by the core team after each feature release.

Who runs PyPI and who pays for it?

The PSF owns and operates PyPI with paid staff and volunteer administrators. Staff are paid from sponsorships and donations, except the PyPI Safety and Security Engineer, who is funded by an Alpha-Omega grant. Much of the hosting is donated.

How do I report a security vulnerability in Python?

Report it privately to security at python dot org or through the GitHub Security Advisory form on the CPython or pip repository. Never post it publicly first.

How do I report a malicious package on PyPI?

Log in, open the project page and choose "Report project as malware" on the Security tab, with a link to the problematic lines through inspector.pypi.io.

Is two factor authentication required on PyPI?

Yes, for all users since 1 January 2024, using TOTP apps or WebAuthn security keys.

What is Trusted Publishing on PyPI?

Publishing from CI without a stored token: PyPI exchanges the workflow's OIDC identity token for a project scoped API token valid for 15 minutes.

What are PyPI digital attestations?

Signed statements, standardised in PEP 740, that bind a file's digest to the workflow identity that published it. PyPI serves them through its Integrity API.

Does the Python Software Foundation pay bug bounties?

No. The python.org security page says the PSF does not run any bug bounty programs.

Is the PSF a CVE Numbering Authority?

Yes, since late August 2023, for Python and pip. Advisories go to security-announce@python.org and to an OSV format database on GitHub.

Where Safeguard fits

The PSF runs the index, the release process and the response process for CPython and pip. What it cannot do is tell you which of those components are running in your own services, at which versions, and which of your projects need an upgrade when the PSRT publishes an advisory. That is the gap Safeguard works in. The Safeguard CLI scans repositories, container images and SBOM files (safeguard scan --dir ., --image, --sbom), matches the components it finds against vulnerability databases, and the platform shows which projects contain a given component and version, so a new CPython or pip advisory becomes a list of affected projects rather than a search. Reachability analysis ranks the vulnerable code paths your application actually calls, and policies and gates evaluated in the platform can stop a known vulnerable version from shipping. The fit is indirect for the rest of this post: Safeguard does not run PyPI, does not take part in PSRT embargoes and does not replace the reporting channels above.

You can try the CLI from safeguard.sh/download, with setup steps in the CLI documentation.

Python dependency hygiene still matters here because every project that installs from PyPI pulls a fresh tree of third party code, and CPython itself bundles third party libraries tracked in its SBOM. When the PSRT or a package maintainer publishes a fix, the remaining risk is the time it takes that fix to reach your builds, and the fit below is about closing that gap rather than anything the PSF does.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and the advisory, asks before each command, edits the dependency to the fixed version, runs the install and the tests with your approval, prints a summary and pushes nothing. The same flow applies when the PSRT publishes a pip advisory or a Python package you depend on ships a security release: you ask for the upgrade, review each step and keep control of what lands.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code, then runs a scan from the terminal. For Python teams that build from a private mirror of PyPI or keep their source off hosted runners, this is how you scan where the code already lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. If your team already asks an assistant questions like "which of our services still run a pip version from before this advisory," this is how the assistant gets access to your Safeguard data, with the tool list set by you.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Python Software Foundation: About
• PSF Bylaws
• PSF Board of Directors
• PSF Membership
• PSF Staff
• PSF Trademark Usage Policy
• PSF 2024 Annual Impact Report
• Python documentation: History and License
• PEP 13: Python Language Governance
• PEP 8016: The Steering Council Model
• PEP 811: Defining Python Security Response Team membership and responsibilities
• PEP 740: Index support for digital attestations
• PEP 541: Package Index Name Retention
• Python Security (python.org)
• python.org: Sigstore verification for Python releases
• Python Developer's Guide: Python Security Response Team
• CPython security policy on GitHub
• PSF advisory database (OSV format)
• PyPI Security policy
• PyPI Docs: Trusted Publishers
• PyPI Docs: Attestations
• PyPI blog: Introducing Trusted Publishers (20 April 2023)
• PyPI blog: Securing PyPI accounts via Two-Factor Authentication (25 May 2023)
• PyPI blog: 2FA Required for PyPI (1 January 2024)
• PyPI blog: PyPI now supports digital attestations (14 November 2024)
• PyPI blog: Project Quarantine (30 December 2024)
• PSF blog: Announcing our new Security Developer in Residence (22 June 2023)
• PSF blog: Security Developer-in-Residence role extended thanks to Alpha-Omega (7 August 2024)
• PSF blog: Security Developer-in-Residence 2023 Q3 Report
• PSF blog: Software Bill-of-Materials documents are now available for CPython (February 2024)
• PSF blog: Join the Python Security Response Team! (February 2026)
• PSF blog: Everything Security at PyCon US 2026
• PSF blog: Open Infrastructure is Not Free: PyPI, the PSF, and Sustainability (October 2025)
• PSF blog: The EU's Proposed CRA Law May Have Unintended Consequences for the Python Ecosystem (April 2023)
• PSF blog: EU's Cyber Resilience Act Passes with Wins for Open Source (12 January 2024)
• PSF blog: New Open Initiative for Cybersecurity Standards (April 2024)
• Apache Software Foundation: How the ASF works
• Apache Software Foundation: Security Team
• Linux Foundation: About

Last reviewed: 23 October 2026. PSF staffing, PEP texts and PyPI policies change over time; check the date and status on each linked page before relying on a specific rule.