If you're asking
in the general case, as opposed to "How would I respond to this call" - my opinion is that the most practical and effective thing you can do is to help secure code used by individuals - web browsers, the Linux kernel, image decoders, etc. I think there are a number of reasons for this:
1) There is a real asymmetry between offense and defense in (nominal) peacetime. Helping the defense generally helps the "good guys" much more than the "bad guys" (at least in my worldview). If you look through attempted attribution of 0day attacks in the wild, what you generally see is repressive governments attacking individuals - watering-hole attacks on news sites, targeted malware against lawyers and journalists, etc. Cases of attacks on governments (like the 2012 MD5 collision that took down an Iranian nuclear reactor) seem to be rarer, and in particular, cases that rely on bugs in mass-market software (as opposed to supply-chain attacks or DoSes or very targeted attacks) are rarer, and attacks from less powerful / "hacker underground" groups towards governments are rarer still.
2) Structurally, it makes more sense. Cyberattacks aren't like physical attacks. When ammunition hits a target, there's a very classical-mechanics effect of the energy of the weapon versus the strength of the structure or shielding. Offense, at a very high level, is about more and stronger weapons, and defense is about withstanding or escaping attacks. Software, naturally, doesn't work that way. It's more mathematical; either the attack works, and is potentially completely compromising, or it doesn't. If you can make a system that robustly parses input without bugs (or sandboxes the parsing, or whatever), there is no cyber-weapon that can get past it.
3) You can make a real impact. A huge number of the systems that ordinarily people use are open-source software projects that accept contributions. (And note that this includes a whole lot of security-sensitive code in system that are not open-source as a whole product - for instance, most of the attack surface on iOS is in WebKit, image parsers, or the xnu kernel.) A lot more is available free-of-charge and accepts security reports. And there is, unfortunately, a lot of relatively low-hanging fruit.
Pick something you're interested in, go look at recent exploitable CVEs, and do some reading on how the exploits work and how they might be systematically prevented. A little bit of your time spent making it easier to systematically prevent exploits has a real long-term benefit on the world.
As a good historical example - most database libraries around 10-20 years ago made it most natural to construct database queries by appending strings together, which made SQL injections entirely too common. Since then, there's been a combination of a push for libraries to make it easier to do parametrized queries, a cultural / documentation push to get programmers to be aware of this, and a move towards database abstractions like ORMs that avoided the problem entirely.
Someone who wrote some docs 10 years ago about these libraries probably helped hundreds of annoyed enterprise programmers get their system built in the right way when their boss was yelling at them about deadlines, and may well have prevented millions of people losing their data in a breach.
When you think about attacks on secure messengers, etc., it's not hard to imagine that the same amount of effort could save countless lives just a few years down the line.
I think memory safety is one of the highest-impact changes we could make in development that would help the cause of defense, and there's a lot of work to be done. Most of it, mind you, is not merely showing up places and saying "I'll rewrite this in Rust" - it's helping people be able to integrate incremental rewrites and ship things in new programming languages, or perhaps helping them avoid memory-safety problems in their existing programming languages. Chrome has a good article on this https://www.chromium.org/Home/chromium-security/memory-safet... , and "fuzzing," the technique of throwing generated inputs at libraries to see where they crash and then fixing those crashes, is also highly valuable.
But there are a whole lot of other similar classes of problems to help with, too. The Linux Kernel Self-Protection Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr... is working on eliminating classes of bugs in the upstream kernel. Some of these have already been addressed, to some extent, in security-focused forks of the kernel, but getting the fixes into the standard kernel is important for getting them in everyone's hands and also a good way to learn about things.