[netwo233gur]

>you're wrong to think this

Security engineer here. No they aren't. I'd say they are being a much more comprehensive in their security analysis by including the cons in their calculation rather than dismissing them and assuming that the pros outweigh them.

>opinion is shared by most of the security community.

No it isn't.

Security by obscurity is a very valid defense-in-depth measure. There's a reason you disable "debug-level logging" on production webservers.

>There is ample evidence that the cons FAR outweigh the pros in this particular comparison.

Show said evidence, please, because there is ample evidence that open source software magically being reviewed by hordes of people is many times a myth.

Heartbleed was caused because pretty much nobody cared to look at openssl's code and review it for vulnerabilities. Just because it is available to be looked at by white hats doesn't mean anyone actually is looking at it. And if something so critical to security like openssl isn't even being reviewed by security researchers, what gives you any confidence that random software like JoesCoolLoggingLibrary is reviewed with any more scrutiny?

Speaking of logging, Log4shell is yet another example. The most ubiquitous libraries in use. Used everywhere by some of the largest tech companies in the world, that all have the largest and most well-budgeted security organizations. The vulnerability was present in code for years, available for anyone in the world to look at, and yet...? Instead, there is evidence that Log4shell was being exploited by black hats before any white hats discovered it.

>You're arguing that 99 white hats don't trump black-vs-white.

No, they're arguing that there is no guarantee that these 99 white hats are somehow better than the 1000 black hats, and I'd add to it that there is also no guarantee that these 99 white hats magically appear, anyway. In fact, I think a more realistic visualization for most software is:

- Closed source:

-- Pros: 1 well paid white hat can easily inspect the source

-- Cons: 1000 hackers can blackbox-attack the application

- Open source:

-- Pros: 1-2 unpaid volunteer white hats might inspect the source if they have time

-- Cons: 1000 black hats can whitebox-attack the application

As a security engineer, I know which one I feel more comfortable with.

[AshamedCaptain]

> Show said evidence, please, because there is ample evidence that open source software magically being reviewed by hordes of people is many times a myth.

It is outright ridiculous ( even malicious) to point to examples of bugs that were found _by 3rd party users reviewing the code_ as evidence of lack of 3rd party code review.

However, try to find evidence of issues found by a 3rd party reviewing a closed crypto system .

There is a literal objective benefit to having an open system, and that is why every engineer worth its salt is nowadays going to consider a closed crypto system as the snake oil it is.

> Security by obscurity is a very valid defense-in-depth measure. There's a reason you disable "debug-level logging" on production webservers.

This is also missing the point. What is meant here is that a crypto system should not rely on obscurity of its design (rather, the design should be open for cryptonanalysis), not that you have to provide friggin debug- level access to every implementation of the system, even production.

[netwo233gur]

>It is outright ridiculous ( even malicious) to point to examples of bugs that were found _by 3rd party users reviewing the code_ as evidence of lack of 3rd party code review.

Those "bugs" were found by third party hackers reviewing the code. Heartbleed was found by someone conducting a blackbox pentest. Log4shell was found by someone reviewing the code, and using the exploit before white hats discovered it as a 0-day. This is the exact opposite of championing open source white hats, and is exactly the concern raised by the original author of the statement which created this entire thread.

>However, try to find evidence of issues found by a 3rd party reviewing a closed crypto system .

I can speak from personal experience at a FAANG that this happens literally every day, multiple times a day. Just because you don't hear about it happening because its behind closed doors does not mean it isn't happening.

>There is a literal objective benefit to having an open system

And there is literal objective disadvantage to having an open system, as well. The entire point is that you must weigh the tradeoffs.

>why every engineer worth its salt is nowadays going to consider a closed crypto system as the snake oil it is.

The majority of software you use is using closed crypto systems. Just because the core algorithm used is open source doesn't mean the rest of the implementation is. The security industry does not view this as snake oil. If you think we do, you have a misunderstanding of the security industry.

>This is also missing the point. What is meant here is that a crypto system should not rely on obscurity of its design (rather, the design should be open for cryptonanalysis), not that you have to provide friggin debug- level access to every implementation of the system, even production.

It seems like you're the one that completely missed the point. Relying on third party cryptanalysis for your security goals (especially by unpaid volunteers, or low-paid bounty hunters) is terrible and lazy security, and will almost certainly not get you what you want. The design of a crypto wallet being open is a product decision made because your users want some level of assurance that you aren't secretly stealing their BTC, but it is not a security decision that can be relied on to secure your product from vulnerabilities.

[lmm]

> Security by obscurity is a very valid defense-in-depth measure.

No it isn't. The whole notion of "defense-in-depth" generally does more harm than good IME, as it creates confusion about where the actual security boundaries are.

> Speaking of logging, Log4shell is yet another example. The most ubiquitous libraries in use. Used everywhere by some of the largest tech companies in the world, that all have the largest and most well-budgeted security organizations.

log4j2 was widely disliked and rarely used, IME.

[netwo233gur]

>No it isn't. The whole notion of "defense-in-depth" generally does more harm than good IME, as it creates confusion about where the actual security boundaries are.

The security departments of multiple FAANGs, not to mention security experts, completely disagree with you.

>log4j2 was widely disliked and rarely used, IME.

Tell that to the tens of thousands of FAANG engineers who worked all weekend remediating the hundreds of thousands (not exaggeration) instances in their companies where it is in use.

[lucideer]

I'm happy to hear you're a security engineer. I'm sure you're the only one here.

> No it isn't. Security by obscurity is a very valid defense-in-depth measure.

No-one has said otherwise. I said this in the gp of the comment you're replying to.

> Show said evidence, please

No need: you've just shown two good examples yourself. Bugs found by scrutinising open source software. I'd be curious to see how many examples you have of the same found in closed-source software (or are you suggesting there's no closed-source software out there with vulns of the same vintage as Heartbleed).

> No, they're arguing that there is no guarantee that these 99 white hats are somehow better than the 1000 black hats

This sentence seems to make the same assumption others have: that "black hats" are exclusively looking at open source software.

> 1-2 unpaid volunteer white hats might inspect the source if they have time

This might be true of a library noone uses (in which the impact of an exploit is limited by it's popularity). For popular libraries, there's an entire SCA industry of commercial vendors selling products that disprove this (transient dependency reporting is done throughout large corps that rely on open source supply chains). Admittedly this industry is more mature in some areas than others (e.g. package-managed language ecosystems -vs- orchestrated system deps), but it's still not insignificant. There's absolutely no comparison between this effort and the number of eyes looking at proprietary products internally in any given org.

[netwo233gur]

>No need:

Yes, need.

>you've just shown two good examples yourself. Bugs found by scrutinising open source software.

Bugs found years after they were introduced, and not found by white hats until after black hats were already exploiting them. This is your example of open source software being secure? These are poor examples, and the exact opposite of what you're arguing for.

>This sentence seems to make the same assumption others have: that "black hats" are exclusively looking at open source software.

It makes no such assumption. You appear to have completely missed the point.

>This might be true of a library noone uses (in which the impact of an exploit is limited by it's popularity). For popular libraries, there's an entire SCA industry of commercial vendors selling products that disprove this

Nope. You again seem to have completely missed the point. Openssl and log4j completely destroy your argument here, as they are two of the most used software packages in history and yet nobody noticed the bugs for years. I don't know how you can champion this as a win for open source security with a straight face. We still do not understand the full extent to which these vulnerabilities were exploited, but we do absolutely know that they were exploited before open source white hat researchers found anything. These were abject failures for open source.

> There's absolutely no comparison between this effort and the number of eyes looking at proprietary products internally in any given org.

You're right that there's no comparison. Right now in my company there are thousands of well-paid engineers whose full-time job is to look for vulnerabilities in our closed-source code bases. The amount of scrutiny that open-source libs get doesn't hold a candle to it.