> The thing that amazes me is that nobody using this software ever did their due diligence.

How could they be expected to? Reviewing all of the source code for log4j is not a walk in the park. Even if you thoroughly reviewed all the source code, would this specific exploit have crossed your mind?

The game theory and assumptions around a "logging" library probably led a lot of organizations to not even consider it a potential threat and focus their efforts elsewhere.

There is also the transitive dependency angle which turns this into more of a plague than a blame assignment session.

> How could they be expected to? Reviewing all of the source code for log4j is not a walk in the park. Even if you thoroughly reviewed all the source code, would this specific exploit have crossed your mind?

Back a long time ago, companies were extremely wary of including any open source library (let alone thousands!) into their product. It took a very long time with audits, lawyers, etc to get a single library approved.

Yes, it was kind of a pain.

So the world has swung into the other extreme these days. Just pull in a couple thousand libraries from the internet, nobody knows what they even are or what's in them. All in the name of speed. So it has its benefits.

But the fundamental concerns of long ago are still there. Bringing in unreviewed third party code is a vector for vulnerabilities, supply chain attacks and all that joy.

I don't expect every user to audit code. But one of the audits I was privvy to was a part of the federal government and had really stringent requirements for the code that they run -- which, of course, includes tracking down all the dependencies, and, yes, is expensive. The fact that this extremely widely-used project never hit such an audit is a curiosity. And a bit of a tragedy of the commons -- many millions of dollars of commerce has depended on this project, and now folks are up in arms because every individual decided that it wasn't their problem to investigate.

Even with an audit and 100% unit test coverage, and static code analysis, vulnerabilities slip through. Software is not perfect and you do not have a silver bullet.

I'd agree if this was the first CVE. But that got some attention to log4j, which quickly exposed two more CVEs. There's no such thing as perfect, but these problems almost certainly would have been caught by a competent security audit.

Has any of your software been through a security audit? Mine has. It’s 99.9% OWASP coverage with some automated fuzzing with almost no imagination applied by the auditors. You’re assigning far too much ability to auditors.

Upthread, I mentioned that I've been party to it three times. And yes, auditor skill and methods vary.

Indeed. Every Node.js/npm installation, ever.

> Reviewing all of the source code for log4j is not a walk in the park.

Traditionally if something is too large to audit then you shouldn’t use it, which few exceptions (like Linux). Maybe this should be a red flag in the future, especially for a logging library that can almost be replaced with a call to stdout and a log collector.