Far as backdoors, the most common way professionals do it is disguise them as normal bugs/vulnerabilities. They werent saboteurs: just slipped like everyone does. ;)
Your comment reminds me of the Underhanded C Contest. Some of the submissions are absolutely dirty, and it goes to show how feasible it is to slip in these kinds if bugs.
That's a nice example of sneaky subversions. Many examples. I do want to emphasize even more that subversions with low consequences will look like most common, vanilla stuff you will see. Most of them won't make UCC since they look too accidental. Article included a common source of problems and subverison opportunities: replacing == with = or other way around. Few would bat an eye when that could just be a finger slip of a hurried programmer.
The other part of things is you don't want to just introduce the defect. It's better to meaningfully improve something so the contributors' image stays good despite problems. So, you want to improve it for performance, readability, or something like that. Then, make sure most of your contributions don't introduce problems. A high-quantity, mostly-positive contributor is a much better saboteur since the bad stuff is both (a) tiny portion of contributions and (b) stuff others screw up on. Therefore, it looks like random defects not worth blocking that contributor.
The fact that things like Linux kernel have hundreds of vulnerabilities a year isn't helping. The baseline is way worse than any saboteur would be contributing. Such insecure-by-default projects make their job much easier. Hell, they can look pretty skilled only adding a few vulnerabilities to a project with that many.
https://events.linuxfoundation.org/wp-content/uploads/2017/1...
Far as backdoors, the most common way professionals do it is disguise them as normal bugs/vulnerabilities. They werent saboteurs: just slipped like everyone does. ;)