Open Source Security Checklist: 14-Item Guide Before Going Public

TL;DR

This 14-item checklist covers the most critical security issues before open sourcing: secrets in git history, repository security, and documentation. 5 critical items must be fixed before launch, 7 important items within the first week, and 2 recommended items when you can.

Quick Checklist (5 Critical Items)

Scan entire git history for secretsDeleted files and old commits still exist in history

Remove or rewrite history if secrets foundUse git-filter-repo or start fresh with squashed commit

Rotate any exposed credentialsIf secrets were in history, assume they are compromised

Create SECURITY.md fileTell researchers how to report vulnerabilities privately

Review for security vulnerabilitiesCheck for SQL injection, XSS, and hardcoded credentials

Secrets and Sensitive Data 5

Scan entire git history for secretsUse trufflehog, gitleaks, or similar. Deleted files and old commits still exist in history. How to scan git for secrets

Remove or rewrite history if secrets foundUse git-filter-repo or BFG Repo-Cleaner. Or start fresh with a squashed commit. How to remove secrets from git history

Rotate any exposed credentialsIf secrets were in history, assume they are compromised. Generate new keys immediately. How to rotate exposed credentials

Create proper example config filesReplace .env with .env.example containing placeholder values. Document required variables. How to create .env.example

Update .gitignoreEnsure .env, credentials, private keys, and IDE settings are ignored before going public. How to secure .env files

Repository Security 4

Enable GitHub secret scanningAlerts you if secrets are accidentally committed after going public. How to enable secret scanning

Enable Dependabot security updatesAutomated PRs for vulnerable dependencies. Essential for maintaining security over time. How to enable Dependabot

Configure branch protectionRequire PR reviews for main branch. Prevent direct pushes that could introduce vulnerabilities. How to configure branch protection

Review GitHub Actions workflowsEnsure workflows do not expose secrets and follow security best practices. How to secure GitHub Actions

Security Documentation 3

Create SECURITY.md fileTell researchers how to report vulnerabilities privately. Include contact and response time. How to create a security policy

Document security considerationsExplain security-relevant configuration options and deployment recommendations in README. How to document security

Add license fileChoose an appropriate open source license. Without one, all rights are reserved by default. How to choose a license

Code Review 2

Review for security vulnerabilitiesCheck for SQL injection, XSS, hardcoded credentials, and other common vulnerabilities. How to do a security code review

Audit dependencies for vulnerabilitiesRun npm audit, pip-audit, or equivalent. Fix critical vulnerabilities before release. How to audit dependencies

Public Means Permanent

Once your code is public, assume it has been scraped and archived. Even if you delete the repo later, someone may have a copy. Secrets committed to public repositories are compromised forever.

Take time to audit before going public. An hour spent checking git history could save you from a major security incident. When in doubt, start with a fresh repo containing only the commits you want public.

Do I need to rewrite git history before open sourcing?

If your git history contains secrets, yes. Even deleted files remain in git history. Use tools like git-filter-repo or BFG Repo-Cleaner to remove secrets from history. Alternatively, start fresh with a squashed commit.

Should I have a SECURITY.md file?

Yes. SECURITY.md tells security researchers how to report vulnerabilities privately instead of creating public issues. Include contact information, expected response time, and any bug bounty information.

What if I accidentally pushed secrets to a public repo?

Immediately rotate all exposed credentials. Then remove them from git history or make the repo private while you clean up. Assume the secrets are compromised regardless of how quickly you act.

TL;DR

Quick Checklist (5 Critical Items)

Secrets and Sensitive Data 5

Repository Security 4

Security Documentation 3

Code Review 2

Public Means Permanent

Do I need to rewrite git history before open sourcing?

Should I have a SECURITY.md file?

What if I accidentally pushed secrets to a public repo?

Related Articles

GitHub Repo Security

Environment Variables

Remove Secrets from Git

Scan Your Repo Before Going Public

Open Source Security Checklist: 14-Item Guide Before Going Public