Python 3.15.0 lands in GitHub Actions: a CI supply-chain checklist

Simon Willison flagged that Python 3.15.0 has been added to actions/python-versions. As a result, you can add "3.15" to a GitHub Actions testing matrix and run your tests against the new release. It is a small piece of news. It is also a useful prompt to look at how your CI obtains its toolchain.

What actually changed

The actions/python-versions repository holds the code and scripts that build Python packages for GitHub's runner images. It also carries a versions-manifest.json listing available and released versions. According to the repository README, some versions come pre-installed on runner images, and others are installed on the fly through the setup-python action. The README also says the builds are only permitted for use by the runner images and setup-python.

With 3.15.0 present, a workflow that requests that version through setup-python can now resolve it. Before that, there was nothing for the action to fetch.

Why a security team should care

The interpreter is the first thing your pipeline runs, and everything after it inherits its behaviour. A CI job that resolves a Python build at run time depends on several things:

• the setup-python action itself;
• the release artefacts it downloads (the setup-python documentation says Python is fetched from GitHub Releases when it is not in the local tool cache);
• the version-resolution rules that choose which build you get.

None of this is a vulnerability. It is an ordinary trust chain. The repository README does not describe checksum, provenance or attestation mechanisms for these builds, so we make no claim about them either way. Because that part of the pipeline sits outside your repository, it is easy to leave unreviewed.

Practical hygiene when adding 3.15

1. 1Pin the version explicitly. The setup-python documentation recommends always setting python-version or python-version-file. It warns that the default PATH version can change unexpectedly between runners.
2. 2Keep the new version in the matrix as a separate job. Test 3.15 alongside your supported versions, and decide deliberately when it becomes a release gate.
3. 3Review the action reference. The documentation examples use a version tag (@v7) and do not discuss commit-SHA pinning. Whether you pin third-party actions to a full commit SHA is a policy decision. Many security teams make it, because tags can be moved.
4. 4Minimise token scope. The documentation recommends contents: read for checkout and dependency installation. Use it unless a job genuinely needs more.
5. 5Pin dependencies as well. The documentation notes that unpinned dependencies undermine cache effectiveness. They also make results harder to reproduce.

The wider point

Early testing against a new interpreter is a cheap way to find which of your dependencies, native extensions or build scripts will break. It is better to learn that on your own schedule than during a forced upgrade after an end-of-life date or a security fix. The same applies to the pipeline itself: knowing exactly which interpreter build ran, and where it came from, is part of being able to explain a build afterwards.

For many teams, adding the matrix entry is a one-line change. The more valuable follow-up is a short review of how each workflow chooses its toolchain, and a note of the answers.