And most open source projects run a fairly transparent dev process - almost by necessity. Doing something like that as an individual dev might be possible, but hard and likely impossible to do structurally (no guarantee to get it in, no guarantee for the project to be picked next year(s), no guarantee for nobody else to find it first, and upon discovery, risk that your scam becomes apparent).
But as a team, the only way to really pull this off involves inserting such vulnerabilities intentionally and out of sight, which means a closed dev process. Even if you orchestrate via some other medium - assuming you're using a VCS, the vulnerability will be publicly traceable to a core contributor - and if you do that regularly, you'll at the become known as a project that's a security nightmare; that might kill the project in the long run. And you might even raise suspicions purely base on the frequency and nature of vulnerabilities.
All in all: abusing this sounds like a fairly risky fraud.
Lots of fraud is risky. And often very worth it if you are very poor and live in a country where laws against fraud aren't enforced. I think the potential for abuse deserves a closer look.
If you look at the question, you can see that some people don't make the connection that the motivation behind code signing is figuring out who committed suspicious code. Code that has security bugs is one interest, another is code which the committer didn't have permission to commit, for example proprietary code.
Thanks for the link. So I submit some code that is signed and it's a good contribution that closes an issue. I intentionally include a subtle bug. My friend who lives in a different country uses the bug bounty program to fix the bug and he collects the money. How do you detect that scenario with code signing?
But as a team, the only way to really pull this off involves inserting such vulnerabilities intentionally and out of sight, which means a closed dev process. Even if you orchestrate via some other medium - assuming you're using a VCS, the vulnerability will be publicly traceable to a core contributor - and if you do that regularly, you'll at the become known as a project that's a security nightmare; that might kill the project in the long run. And you might even raise suspicions purely base on the frequency and nature of vulnerabilities.
All in all: abusing this sounds like a fairly risky fraud.