Comment by oefrha
4 years ago
The argument isn’t having no eyes is better than some eyes. Rather, it’s commonly argued that open source is better for security because there are more eyes on it.
What this research demonstrates is that you can quite easily slip back doors into an open contribution (which is often but not always associated with open source) project with supposedly the most eyes on it. That’s not true for any closed source project which is definitely not open contribution. (You can go for an open source supply chain attack, but that’s again a problem for open source.)
> it’s commonly argued that open source is better for security because there are more eyes on it.
> What this research demonstrates is that you can quite easily slip back doors into an open contribution
To make a fair comparison you should contrast it with companies or employees placing a backdoors into their own closed source software.
It's extremely easy to do and equally difficult to spot for end users.
Recruiting a rogue employee is orders of magnitude harder than receiving ostensibly benign patches in emails from Internet randos.
Rogue companies/employees is really a different security problem that’s not directly comparable to drive-by patches (the closest comparison is a rogue open source maintainer).
Maybe for employees, but usually it is a contractor of a contractor in some outsourced department replacing your employees. I'd argue that in such common situations, you are worse off than with randos on the internet sending patches, because no-one will ever review what those contractors commit.
Or you have a closed-source component you bought from someone who pinky-swears to be following secure coding practices and that their code is of course bug-free...
The reward for implanting a rogue employee is orders of magnitude higher, with the ability to plant backdoors or weaken security for decades.
And that's why nation-state attackers do it routinely.
2 replies →
To make it a fair comparison you should contrast... an inside job with an outside job?
This is an arbitrary definition of inside vs outside. You are implying that employees are trusted and benign and other contributors are high-risk, ignoring than an "outside" contributor might be improving security with bug reports and patches.
For the end user, the threat model is about the presence of a malicious function in some binary.
Regardless if the developers are an informal community, a company, a group of companies, an NGO. They are all "outside" to the end user.
Closed source software (e.g. phone apps) breach user's trust constantly, e.g. with privacy breaching telemetries, weak security and so on.
If Microsoft weakens encryption under pressure from NSA is it "inside" or "outside"? What matters to end users is the end result.
2 replies →