🔍 Why You Must Secure What You Publish

When your organization publishes or maintains open source code, you take on real responsibility—not just for quality, but for security. Compromised repos, hijacked maintainers, or malicious PRs can lead to supply chain attacks that affect thousands of downstream users. Being an open source publisher means becoming a security steward.

This post outlines actionable steps to protect your Git repositories, package registries, contributor workflows, and the reputation that goes with them.

🔑 Lock Down Your Repositories

Whether you host on GitHub, GitLab, or another platform, follow these security-first practices:

• Enable branch protection: Require PR reviews, signed commits, and status checks on main or release branches.
• Enforce 2FA/MFA: Require multi-factor authentication for all maintainers and admins.
• Use least privilege: Don’t give full admin rights to casual contributors—use role-based access (e.g., triage, write, admin).
• Monitor for force pushes, tag deletions, or branch creation—signs of compromise or misuse.

🔐 Secure the Release Process

Attackers often target the release flow, not just the source code. Secure your artifact build and publication steps:

• Sign releases: Use GPG or Sigstore to cryptographically sign release artifacts (tarballs, JARs, NPM packages).
• Use isolated CI/CD runners: Build and sign releases in ephemeral, hardened environments.
• Verify packages before publish: Perform linting, dependency scanning, and static analysis before pushing to PyPI, NPM, etc.

If you use GitHub Actions, ensure secrets are scoped only to specific workflows and rotated frequently.

🧪 Validate External Contributions

Don’t trust public pull requests at face value. Instead:

• Use PR templates: Require contributors to explain changes and provide test coverage.
• Run automated security scans: SAST, dependency scans, and policy checks before review.
• Implement CODEOWNERS: Ensure experienced maintainers review sensitive modules or configurations.

Adopt a “zero trust” mindset toward inbound code—even from known contributors. Mistakes and malicious intent both happen.

📦 Secure Package Registry Access

If you publish to public registries (e.g., PyPI, NPM, Maven Central):

• Use scoped access tokens: Avoid global or user-bound tokens. Rotate credentials regularly.
• Monitor package updates: Keep an eye on who is publishing, what versions are being pushed, and from where.
• Set up two-person release approvals: Especially for critical libraries, never allow solo publishing without review.

Registries are increasingly targeted—hardening your access and audit practices is critical.

📣 Communicate Responsibly

Responsible maintainers make it easy for users to trust them—and report problems. Every public repo should include:

• SECURITY.md with coordinated disclosure instructions
• Signed release notes with changelogs and known risks
• Transparency about deprecated features or end-of-life schedules

For mature projects, consider registering a security.txt file in your domain root to standardize contact and PGP key info.

🛠️ Tools That Help

• Sigstore: Keyless signing of artifacts and commits
• OSV Scanner: Check for vulnerabilities using Google’s OSV database
• OSS Review Toolkit: Review licenses and vulnerabilities in project trees
• GitHub CodeQL: Custom SAST scanning for OSS projects

Most tools have GitHub Actions or CLI integrations to make secure development easy to embed into your publishing workflows.

📣 Final Thought

If you’re publishing code, you’re publishing trust. As an open source maintainer, your repository may be one step away from someone’s production system, medical device, or national infrastructure. Harden your repo, vet your releases, and treat publishing as a secure-by-default process.

Need help reviewing your OSS publishing practices, securing your build workflows, or designing a secure contribution model? Let’s talk.