A supply chain security program for open source maintainers from zero

A maintainer can build a useful supply chain security program in a weekend by doing four things in order: protect accounts and the default branch, publish through short lived credentials, pin what your builds consume, and publish a way for people to report vulnerabilities. Measure progress with a public scorecard.

Why start with the maintainer, not the code?

Most attacks on open source packages do not need a bug in your code. They need your publishing credentials, your release workflow or a change merged without review. So the first controls protect people and process.

Imagine a constructed project: a small parsing library with two maintainers, 3,000 weekly downloads and a GitHub Actions release job that uses a long lived registry token stored as a repository secret. That token is the asset worth protecting.

What can you measure yourself against?

The OpenSSF Scorecard runs automated checks on a repository and gives each a risk label. Two are a good starting pair. Branch-Protection is rated High risk, "vulnerable to intentional malicious code injection", and tests whether default and release branches use branch protection or repository rules. Pinned-Dependencies is rated Medium, "possible compromised dependencies", and tests whether build and release dependencies are pinned to a specific hash instead of a mutable reference.

Running Scorecard on your own project shows what an outsider would see, and its documentation lists remediation steps for each check.

Step 1: Protect the branch and the account

Turn on branch protection for the default branch so changes need review and passing checks. Require strong sign in on every maintainer account. Keep the list of people with write access short and review it each quarter.

Step 2: Stop publishing with long lived tokens

npm documents trusted publishing, which lets you publish directly from CI workflows using OpenID Connect authentication and removes the need for long lived npm tokens. Other registries have similar features, so check your ecosystem's documentation. In the constructed project, replacing the stored token with OIDC means a leak of the repository secrets no longer yields a way to publish.

npm also documents provenance statements, which publicly establish where a package was built and who published it.

Step 3: Pin what your build consumes

Pin third party actions in workflow files to full commit hashes, and let an update bot propose changes in reviewable pull requests. Commit your lock file. Install from it in CI with the strict command your package manager offers. GitHub documents Dependabot alerts, generated when a dependency in the dependency graph has a known vulnerability, and optional automatic pull requests for updates.

Step 4: Give reporters somewhere to go

GitHub's documentation recommends that maintainers add a SECURITY.md file to say how to contact them and collaborate on vulnerability reports. Add one with a monitored address and the response time you can really keep. Turn on secret scanning if your plan includes it, so a committed credential is flagged.

What about a software bill of materials?

Publish one with each release if downstream users ask, generated from your lock file. It saves them time and costs you a build step. Do not let it replace the earlier steps.

How to check or apply this

1. Run OpenSSF Scorecard on your repository and note the failing checks.
2. Enable branch protection or repository rules on default and release branches.
3. Review who has write and publish access, and remove anyone inactive.
4. Move releases to trusted publishing or the closest equivalent in your registry.
5. Pin workflow dependencies to hashes and commit lock files.
6. Add SECURITY.md and monitor the contact address.
7. Re-run Scorecard each quarter and write down what changed.

Quick check

Sources

• OpenSSF Scorecard
• Scorecard checks documentation
• npm Docs, Trusted publishing for npm packages
• npm Docs, Generating provenance statements
• GitHub Docs, Securing your repository

Last reviewed: 18 October 2026.