Supply Chain Security is FUBAR - A Proposal for GitHub

Three things GitHub could do to vastly improve security capabilities

This post is about how we can solve the security problems highlighted by tj-actions and xz utils.

I spent most of Saturday night and Sunday morning trying to verify with certainty that the attack against tj-actions was caused by a breached GitHub token as the maintainer, Tonye, stated here, or if it was possible that they did it themselves. After all that investigation, the best I can say is that it’s likely the Personal Access Token (PAT) was taken over, and there’s no special reason to suspect the maintainer of malicious intent; however, there’s really no way to verify from the outside with certainty.

Finally throwing in the towel on knowing with certainty (as all try hard security people try to do), I knew the dire situation Supply Chain security is in. Ultimately, the community doesn’t have enough ways to secure their open source, and it’s mostly GitHub’s ($2B revenue) fault. “Open Source Reputation scores” from SCA scanners are generally just noise, and I’d argue it’s partly because they don’t have enough data to be really helpful. If I can’t even confirm that a maintainer is a real person, what does that say about how much our SBOMs matter?

Instead of complaining about companies not sponsoring their maintainers, or not pinning their commits to prevent exploits, or advocating for new ways to make CVEs disappear, here are 3 things GitHub could do to fix this crap:

1. When a repo hits a “verified stars” or other popularity threshold, require:

   1. Signed commits

   2. Changes must happen via pull request

   3. No bypassing for force pushes

   4. 2FA for all admin credentials and maintainers

   5. Allow Overrides for Emergency Fixes: If absolutely necessary (e.g., urgent patch), maintainers could bypass these requirements, but GitHub would log and surface that bypass publicly, and downstream consumers could fail their builds if the commit reflects this.

   6. If GitHub is scared to make this a requirement: make it optional, guide users towards these settings as their repos get more popular, and surface whether or not their turned on via an API, as I’ll talk about in point 3.

2. Create an opt-in standard for open source maintainer identity verification with:

   1. Voluntary Verified Maintainer Program: Provide a process (similar to Twitter’s “Verified” check, or LinkedIn’s identity verification, but for developers) where maintainers can submit official identification or verifiable contact info to GitHub.

   2. “Maintainer Roster Changes” Alerts: When a repository has opted into verification and gains or loses a maintainer with write or admin access, a simple automated notice appears in the repo’s feed (and potentially in a dedicated “Security Updates” feed).

3. Allow maintainers to share their repo’s audit logs and security settings publicly

   1. Configurable Public Audit Log: For open-source repositories, allow owners to publish a read-only version of audit logs to the public if they opt in, or a partial audit log that shows potentially sensitive actions like pushes. This might include records of code pushes, role changes, forced pushes, and significant security events.

   2. Public Security Settings Overview: Provide a “security dashboard” page that shows which security features (dependabot, secret scanning, required reviews, protected branches, OpenSSF, etc.) are enabled, so the community can see the status at a glance, and use APIs to automate what security standards they need enforced according to their risk posture.

4. (Optional helpful things) Actually do the things in this roadmap item from 2022, indicating immutable action versions, build attestations, and built in malware scanning

   1. Implement a real version of Chainguard’s octo-sts service to create short lived credentials for automated actions in runners, with documentation on moving to them from PATs.

   2. Check for similarly named GitHub actions to prevent attempts to trick users with malicious copies of common actions.

Until GitHub implements these changes, the best we’ll be able to do is flash a risk score at companies about their open source dependencies based on generic data like “most recent commit,” and continue to watch them scramble when they’re breached in new and interesting ways.

Companies need ways to verify identities and security settings, with an audit log to prove it, and ultimately I can complain about the need to use Tidelift to support maintainers all I want, but only GitHub can really fix this.