Excuse me if I don’t want to hear your “hot take” on the Log4j vulnerability. By all means, give me the details of what happened, as well as how it’s impacting companies like mine. Even better, give me insight into how I can test my servers to see if I’m safe.
Just don’t blare headlines like “Open source can be [an] open door for hackers,” as the Financial Times did. And don’t use the problem to start banging the drum of “open source sustainability” crises. Open source isn’t a security problem, and open source sustainability is a complicated issue. Instead, it’s time to recognize, as Matt Klein, founder and maintainer of the Envoy open source project, has done, that “All we can do is accept the reality of bugs/outages, do the best that we can to mitigate, learn, and improve, and wait for the next one.”
SEE: Patch management policy (TechRepublic Premium)
Making security a process
I know, I know! That doesn’t make for exciting reading. There’s no smoking gun. No intern to blame. It’s just…software. And software breaks, is buggy, etc.
As Klein stressed,
I’ve avoided a hot take on the log4j situation because frankly I’m tired of tech hot takes. However, my not hot take hot take is that bugs happen, some of them very bad, and they occur for a set of complex reasons. Complaining about the villain of the day ([open source] funding, memory safety, etc.) is a red herring, and over-focusing on one cause leads to no real improvement. We are all human and juggling a mountain of constraints; it’s a miracle that tech works 1% as well as it does.”
But…what about the fact that apparently the Log4j maintainers may not be paid to do that work? That may or may not be true, but it’s also somewhat immaterial, as Red Hat’s Andrew Clay Shafer argued: “[P]aying [open source] maintainers fully competitive software salaries would have a negligible impact on preventing log4j like security issues.” On its face this sounds wrong, but consider his follow-up: “[H]ow much money have banks spent on ‘security’ since 2013? [W]hile running log4j in prod the whole time? [H]ow many undiscovered exploits are in prod at your bank right now?”
He has a point. A good one.
Even the most fully funded software has bugs, security holes, etc. We can absolutely do better, but no software – open source or proprietary – is immune from flaws. Sure, it might make the maintainers feel better to be paid while they’re yelled at to “FIX THIS NOW!” but there are some (like Beka Valentine) who would argue that reducing all open source sustainability to a question of money unwittingly takes away some of its greatest strength: developer passion.
SEE: Log4j: How to protect yourself from this security vulnerability (TechRepublic)
Indeed, on this point, Ruby on Rails founder David Heinemeier Hansson declared that “I won’t let you pay me for my open source.” Why? “Open source, as seen through the altruistic lens of the MIT gift license, has the power to break us free from this overly rational cost-benefit analysis bulls— that’s impoverishing our lives in so many other ways.” In other words, he wants people to contribute if it gives them joy, and he doesn’t want to feel beholden to do anything with the project that doesn’t also bring him happiness. Introducing money makes open source common, in his view.
Regardless of whether you agree, and coming back to Shafer’s point, we won’t magically rid Log4j or any open source (or proprietary) software of bugs simply by throwing money at them. That’s not the magic of open source. No, security is a process in open source, not something you get by licensing code under an open source license. I tweeted in December 2020: “Not that open source is inherently more secure, but rather it’s an inherently better process for securing code.”
By all means, let’s ensure open source contributors are paid (or not, following the reasoning of DHH and Valentine), but let’s not celebrate our silly hot takes that try to reduce the Log4j problem to one thing. Security is complicated. Software is complicated. But open source, by making the software and surrounding processes permeable, accessible, improves security (or can), rather than degrading it.
Disclosure: I work for MongoDB, but the views expressed herein are mine.