About • Blog • Newsletter • Links

Security Developer-in-Residence – Weekly Report #1

Published 2023-06-30 by Seth Larson
Reading time: 5 minutes

This critical role would not be possible without funding from the OpenSSF Alpha-Omega Project.
Massive thank-you to Alpha-Omega for investing in the security of the Python ecosystem!

Welcome to the first report from me fulfilling the role of Security Developer-in-Residence (SDIR). Since this role serves the Python community I would like to make publishing these reports weekly to give some insights into what I'm working on and thinking about.

This report covers a bit more time than a single week because I started the job on a short week and was in stealth mode until Thursday of last week so there was a limited amount of things and people I could engage with publicly.

Meeting all the people!

The focus of the past week has been meeting all the lovely folks I'll be working closely with to achieve this role's mission. Below is a subset of the folks I met with or made introductions with:

To no surprise at all knowing the Python community: Everyone I've met has been very warm, welcoming, and excited to collaborate. There are many familiar faces and existing relationships between me and the folks listed above which highlights one of the big benefits for filling roles like the SDIR from existing community members.

Python Security Response Team

After announcing myself and my mission to the CPython Core Developers I was quickly invited to join the Python Security Response Team (PSRT) in order to help with triaging and responding to security reports for CPython. So now when you email security@python.org there's a chance I'll be the one helping you out. I've also become a moderator of the mailing list to help with sorting through spam and invalid requests.

In addition to joining the team, I've been gathering feedback from members of the PSRT in order to improve the processes that already exist. From listening to folks, I've heard three common topics and have put together a set of proposed changes to be discussed by PSRT members and ultimately approved by the Python Steering Council. The three topics I've heard are:

Since the discussions are quite early on I will hold off on details until the next update where I provide more information.

OpenSSF Working Groups

Part of the role is sharing the perspective of the Python ecosystem in working groups like the ones hosted by the OpenSSF. I have identified the following meetings to contribute to regularly and was able to attend most of them that occurred this week and introduce myself:

Securing Critical Projects WG

Caleb Brown shared a project on malicious package detections on multiple different package repositories, including PyPI. The next stage of the plan is to start hooking this data source up to data intakes.

I pointed Caleb towards the recent funding that PyPI has received from the Center for Security and Emerging Technology in order to develop functionality around an API to accept malware reports from trusted sources and to use this information for quicker resolution times and potentially automated resolution via soft-deletes of releases.

The entire group was excited for this work and will be following closely. Caleb will engage with the PyPI project through the provided Google form intended to gather information from groups that are already doing this sort of malware analysis.

Securing Package Repositories WG

Zach Steindler presented a draft guide for helping other package repositories add build provenance through in-toto and SLSA. This guide uses NPM provenance as an example and shows how that work can be replicated by other repositories.

The draft guide also mentions that using OpenID Connect for authentication similar to PyPI's Trusted Publishers are a great first step towards build provenance since they don't require the use of Sigstore but build on the same primitives as would be needed for build provenance.

Even where there is no availability of OpenID Connect, like when building+publishing from your own computer, there is still some attestation that the package repository can provide installers. For NPM this is called a "publish attestation" and similarly uses in-toto but only contains the package name (PURL), version, digest, and registry. This attestation doesn't provide provenance for the package.

Trusted Publisher adoption

Trusted Publishers are already a big operational security improvement for packages publishing to PyPI and as you've seen above may be only the first step on being able to provide build provenance for Python packages. Due to this, I would like to drive adoption of Trusted Publishers in as many Python packages as possible.

It's tough to improve what you're not measuring, so I've submitted my first pull request to Warehouse to add metrics for the number of projects that have configured and successfully used Trusted Publishers. My plan is to use this data to create public dashboards similar to the 2FA adoption dashboards so we can track how adoption over time.

I also created a proposal to nudge users of the popular pypa/gh-action-pypi-publish GitHub Action to use Trusted Publishers since most folks using GitHub Actions for releases can likely already adopt Trusted Publishers.

Security news in the Python-verse

That's all for this week! 👋 If you're interested in more you can read next week's report.

Thanks for reading! ♡ Did you find this article helpful and want more content like it? Get notified of new posts by subscribing to the RSS feed or the email newsletter.


This work is licensed under CC BY-SA 4.0