Security on a Volunteer Budget.

Many civic-tech projects are maintained by two or three people with day jobs. There is no security team, no on-call rotation, no budget line for audits. There is whoever has commit access and a free evening. That used to mean security was something you hoped for. It doesn't have to anymore, because most of what a small team needs is now free, open, and already sitting next to the code.

Start with accounts. Nobody has to break your cryptography if they can log in as you. GitHub announced in May 2022 that everyone contributing code to GitHub.com would need two-factor authentication by the end of 2023. When it reported back, GitHub said it had seen an opt-in rate of nearly 95% across code contributors and a 54% increase in 2FA adoption among all active contributors, with nearly 1.4 million passkeys registered. The package registries followed. PyPI has required 2FA for all users since January 1, 2024. On npm, after the Shai-Hulud worm spread through compromised maintainer accounts, GitHub removed more than 500 compromised packages and said publishing would be limited to 2FA-protected local publishing, short-lived granular tokens, and trusted publishing. By December 2025 npm had permanently revoked all classic tokens and enforced 2FA for publishing.

For a small team the most useful piece is trusted publishing. Instead of storing a long-lived API token in CI, where it can leak, the registry trusts a specific workflow in a specific repository and hands it a short-lived credential at release time. npm made this generally available in July 2025 for GitHub Actions and GitLab CI/CD. On PyPI it is already ordinary: about 45,000 projects had configured it by November 2025, and it accounted for over 25% of files uploaded in a month, up from about 10% in early 2024. If your team publishes packages, this is the first afternoon to spend.

Trusted publishing on PyPI

projects configured by November 2025

~45,000

projects configured by November 2025

• Share of uploaded files, February 2024 10%
• Share of monthly uploads, October 2025 25%

PyPI reports "about 10%" in February 2024 and over 25% of monthly uploads by October 2025.

Next is dependencies, because your project is mostly other people's code. Two habits do most of the work. Commit your lockfiles, so every build installs exactly what you tested. Then let a bot propose updates, so patching is a code review instead of a project. GitHub's Dependabot is available on every GitHub plan. If you host elsewhere, or want something you can run yourself, Renovate is AGPL-licensed and works on GitLab, Bitbucket, Gitea, Forgejo and others. To check what you already ship, OSV.dev aggregates open-source vulnerability data from sources such as GitHub Security Advisories, PyPA, and RustSec, and osv-scanner, an Apache-licensed command-line tool, checks your lockfiles against it. Neither ties you to a hosting provider.

Once those basics are in place, it helps to have an outside view. OpenSSF Scorecard runs a set of automated checks and gives each a score from 0 to 10: whether branches are protected, whether dependencies are pinned, whether CI workflows have dangerous patterns, whether releases are signed, whether there is a security policy. The project already runs it weekly over the 1 million most critical open-source projects, so your repository may have a score you have never looked at. Treat it as a checklist written by people who have seen a lot of incidents, not as a grade. Some checks, like fuzzing, may not be worth it for a small data pipeline. Most of the rest are.

Signing releases used to mean managing a private key, which for a volunteer team meant losing a private key. Sigstore removes that step. It is free, open source, and backed by OpenSSF; it signs with short-lived keys tied to an identity and records every signature in a public transparency log. You may already be using it without knowing. npm package provenance, introduced in April 2023, is signed with Sigstore, and trusted publishing on npm now produces provenance by default. PyPI added Sigstore-based digital attestations in November 2024, generated by default for projects that publish from GitHub Actions through trusted publishing with the standard PyPA publish action.

Provenance is also the entry point to SLSA, a framework that grades how much you can trust a build. You do not need to memorize it. At Build Level 1 a package has provenance showing how it was built; at Level 2 the build runs on a hosted platform, so forging that provenance takes a deliberate attack; Level 3 hardens the build itself. A small project that publishes from a hosted CI with trusted publishing is already most of the way to Level 2 without doing anything exotic.

A software bill of materials is the other document worth producing. It is a machine-readable list of what your release contains, and the people most likely to ask for one are the public agencies that deploy your tool. There are two open formats: CycloneDX, published as Ecma standard ECMA-424 and stewarded with OWASP, and SPDX, an international standard as ISO/IEC 5962:2021. Pick whichever your users' tooling expects.

Secrets are the mistake everyone makes once. GitHub said that in the first eight weeks of 2024 it detected over 1 million leaked secrets on public repositories, and in the same post turned on push protection by default for pushes to public repositories. Secret scanning, push protection, and code scanning are all available for public repositories by default. That means a pasted API key gets blocked before it becomes part of history you have to rewrite.

The last two pieces cost nothing but time. Keep a backup of everything that is not in git: issue history, release artifacts, CI configuration, the DNS login. And write down what you will do when something goes wrong, before it does. OpenSSF's guide to coordinated vulnerability disclosure includes a SECURITY.md template and notification templates, and GitHub lets public repositories receive vulnerability reports privately instead of in public issues. For the plan itself, Netty's incident response plan is a good model: it names roles for leading, fixing, communicating and handling infrastructure, then admits that "the same person might wear multiple hats here." On a team of two, that is the whole team, and a page written on a quiet day is worth more than a good memory on a bad one.

Put together, this is a baseline that used to need a paid security team: enforced strong authentication, automated patching, vulnerability matching, signed releases with provenance, SBOMs, secret blocking, and a disclosure process. Much of it is open source itself, and the hosted parts are free for public repositories. That is a concrete way open source helps the communities that rely on it. A neighbourhood transparency tool can ship with the same release hygiene as a large vendor, because most of these tools are given away.

None of it is automatic, and none of it replaces review by someone who knows the code. This is the floor, and plenty of projects still aren't standing on it.