You could help open source projects get their code into Coverity, a static analysis tool. It helps if they have a github repo, and it's even better if they use Travis-CI.
Using Coverity will help identify some security issues that can be mitigated right away.
Secondly, you can fuzz FLOSS software, using something like afl-fuzz, American Fuzzy Lop. The following tutorial has some pointers to get started, and obviously software written in C is easier to get started with. If you need help with something, feel free to ask on the afl-users mailing list.
You can fuzz on a CPU-heavy VM somewhere, like DigitalOcean, an Amazon spot instance, or a Google preemptible instance.
In fuzzing, once you get the hang of it, you'll find that your keyboard time is the limiting factor. You'll set up a test case in 15-20 minutes, leave it fuzzing for a day, and come back to spend at least 1-2 hours working through crashes and reporting the bugs through their channels.
You may be saying "Wait I don't know anything about C," but honestly, I don't know anything about C either, and I've found hundreds of bugs with fuzzing. There are some crash dump investigation tools that give you an idea of the nature of the crash (gdb's exploitable.py) and that's usually enough to report to the maintainer. When the maintainer has a fix released, you can send an email to the oss-security mailing list detailing what you know about it. MITRE can assign a CVE on the mailing list if you describe the bug appropriately when you ask for one.
Secondly, you can fuzz FLOSS software, using something like afl-fuzz, American Fuzzy Lop. The following tutorial has some pointers to get started, and obviously software written in C is easier to get started with. If you need help with something, feel free to ask on the afl-users mailing list. You can fuzz on a CPU-heavy VM somewhere, like DigitalOcean, an Amazon spot instance, or a Google preemptible instance.
https://fuzzing-project.org/tutorials.html
In fuzzing, once you get the hang of it, you'll find that your keyboard time is the limiting factor. You'll set up a test case in 15-20 minutes, leave it fuzzing for a day, and come back to spend at least 1-2 hours working through crashes and reporting the bugs through their channels.
You may be saying "Wait I don't know anything about C," but honestly, I don't know anything about C either, and I've found hundreds of bugs with fuzzing. There are some crash dump investigation tools that give you an idea of the nature of the crash (gdb's exploitable.py) and that's usually enough to report to the maintainer. When the maintainer has a fix released, you can send an email to the oss-security mailing list detailing what you know about it. MITRE can assign a CVE on the mailing list if you describe the bug appropriately when you ask for one.