Before you publish an open source project, scrub the history for secrets and private data, protect the accounts that can publish, add a security policy, build releases in automation, and decide how reports will reach you. It takes about a day and avoids the mistakes that are hardest to undo.
Clean the repository
- Search the full history, not just the latest commit. API keys, internal host names, customer names in test data and personal email addresses all hide in old commits. If you find a real secret, revoke it. Rewriting history does not un-leak it.
- Check licences. Every dependency and every copied snippet needs a licence compatible with yours. Pick your own licence deliberately and include the file.
- Remove internal references. Comments naming internal tickets, staging URLs and employee names.
- Review the build files. Scripts that download from private locations will break for others and may reveal infrastructure.
Protect the publishing path
- Multi factor authentication on every account that can publish or change the repository, preferably with hardware keys or passkeys.
- More than one maintainer with admin rights, so one lost account does not end the project. Keep the list short.
- Branch protection on the default branch: required review, required checks, no force pushes.
- Publish from CI, not from a laptop. Use short lived credentials or trusted publishing where your package registry supports it. Check the registry documentation for the current options.
- Pin the actions and tools your pipeline uses to specific versions or digests, and give the pipeline the least permissions it needs.
Make it safe to use
- Provide checksums and, where your ecosystem supports it, signatures or provenance for releases, and document how to verify them.
- Publish a software bill of materials with each release so users can see what you depend on.
- Keep the dependency list small. Each addition is something you must watch for the life of the project.
- Turn on automated dependency update pull requests and security alerts in your hosting platform.
Plan for reports
Add a SECURITY.md file that says how to report a vulnerability privately, what response time people can expect, and which versions you support. Turn on private vulnerability reporting if your host offers it. Decide in advance how you will issue an advisory and request a CVE identifier if the issue warrants one.
Be honest in the file. "Best effort, one maintainer, a week" is better than a promise you cannot keep.
After launch
Watch for look alike packages with similar names, and register obvious variants on registries you care about. Set a calendar reminder to review access every quarter, and remove people who have gone quiet.
Safeguard's free scan at gold.safeguard.sh/scan can check a project's dependencies before you publish.
Quick check
I found a secret in old history. Is deleting it enough?
No. Revoke and replace the secret first. Clean the history second, and assume anyone who cloned earlier still has it.
Do I need to sign releases?
It is strongly worth doing where your ecosystem makes it practical, because it lets users check that a release came from you. Document how to verify it.
Last reviewed: 19 October 2026.
