Pick a project you already use, confirm it is active with responsive maintainers, read its contributing guide and security policy, and start with a small change such as documentation or a test. Security sensitive findings follow a different path, covered below, and should never be posted in a public issue.
Why start with software you use
The Open Source Guides advise choosing projects you already use, because you will learn more and stay engaged longer. For an AppSec learner there is a second benefit: you already know what the project is meant to do, so odd behavior stands out.
Check project health first
The same guide suggests checking for recent commits, responsive maintainers, merged pull requests and a friendly tone before you invest time. A quick pass takes ten minutes.
| Signal | Where to look |
|---|---|
| Recent activity | Commit history and releases |
| Responsiveness | Time to first reply on recent issues |
| Acceptance | Recently merged outside pull requests |
| Rules | README, CONTRIBUTING, code of conduct |
| Security path | A security policy file or private reporting |
GitHub's community standards checklist, in the Insights tab, lists the README, code of conduct, contributing guide, license and security policy in one place.
Read before you write
The LICENSE tells you whether it is open source at all. The README explains the project. CONTRIBUTING describes the process, including tests and templates. Past issues and pull requests show the community's norms.
Good first changes for a security minded newcomer
- Fix unclear security guidance in the docs.
- Add a missing test for input validation.
- Update a dependency that has a fixed version listed, if the project welcomes it.
- Improve an error message that leaks too much detail, after asking first.
Filter issues by the help wanted and good first issue labels. For unlabeled issues, ask a maintainer whether a pull request would fit before you start.
What not to do
Do not open a public issue describing an exploitable flaw. Do not run scanners against a project's hosted services. Do not submit a large unrequested rewrite. If you believe you found a vulnerability, use the reporting path in our guide on how to report a vulnerability in an open source project.
Be responsible for what you submit
The Open Source Guides remind contributors to review any AI assisted output themselves, because you are responsible for what you submit. Test your change, follow the project's style even if it differs from yours, and announce your intent in the issue before starting.
Quick check
Should I ask before working on an issue?
Yes. Comment that you plan to work on it, to avoid duplicate effort and to confirm the change fits the project.
What if nobody replies to my pull request?
Follow up politely in the same thread after about a week, and keep the conversation public unless it concerns a security issue.
Sources
Last reviewed: 19 October 2026.
