If your project receives funding, spend the first slice on protecting the accounts and processes that publish your code: hardware security keys, a second reviewer's time, a security review of the release pipeline, backup access, and paid time for the unglamorous fixes. These reduce the chance that one bad day undoes years of work.
Why security is a good first spend
A project's value to its users is trust in what it ships. The cheapest attacks go after the human and the pipeline, not the code. Money that hardens those two things protects every user at once. No funding figures are quoted here, because needs vary widely. The ordering matters more than the amount.
A prioritised list
1. Hardware security keys, two per maintainer. One for daily use and one as a backup stored elsewhere. Phishing-resistant sign-in on the accounts that publish is the highest-value control for the money. See ranking maintainer 2FA methods.
2. Paid review time. Pay a trusted second person to review risky changes: workflows, release scripts and dependency updates. This turns the two-person rule from a hope into a routine.
3. A review of the release pipeline. Ask an experienced engineer to read your workflows, tokens and publish steps and write down what they find. Fixing permissions and secrets there removes whole classes of risk. Start from the release checklist.
4. A succession and recovery plan. Time to set up a co-maintainer, recovery codes and documented access, so the project survives a lost account or a lost person. See recovery codes and backups.
5. Time for the backlog nobody wants. Dependency updates, deprecation work and documentation for reporters. Boring work is where many incidents begin.
What to hold off on
- A formal bug bounty before you can triage reports quickly. See bug bounty readiness.
- Expensive tooling you will not have time to read the output of.
- A long audit of code when the publishing account is still protected by a password alone.
Be transparent
Publish what the money is spent on. A short note in the README or a yearly summary builds trust with sponsors and shows that security is a funded activity. Many sponsors, including companies, like being able to point to this.
If you are the sponsor
Companies that depend on a project can help beyond payment. See how to help maintainers without money and GitHub Sponsors for companies.
Check tax and rules locally
How funding is received and reported depends on your country and platform. Check the platform's rules and your own obligations before you plan spending.
Quick check
What is the single best first purchase?
Hardware security keys for each person who can publish, with a backup key each.
Should I fund a bug bounty early?
Usually not until you can triage and fix reports quickly.
Last reviewed: 19 October 2026.
