Funding Is Just One Piece of the Log4j Puzzle – InApps Technology 2022

Last week, we looked at a number of responses to the Log4j vulnerabilities, which all seemed to lead to one conclusion — a big “I told you so” regarding the effects of lack of funding in open source software.

One writer called the entire situation “a perfect microcosm of all of the major ecosystem problems with ‘Open Source’ software,” while another said that the situation was an obvious example that it was time to “professionalize” the role of open source maintainer. PuTTY maintainer Andrew Ducker said simply that the internet (and large companies) relying on software maintained by people in their spare time, for free, “may not be sustainable.”

While the lack of funding in open source is certainly a problem, could funding have prevented the Log4j vulnerabilities? Would funding actually prevent similar vulnerabilities in the future?

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.

— Matt Klein (@mattklein123) December 14, 2021

The Open Source Security Foundation (OpenSSF), among many others, took issue with this oversimplified way of looking at a much more complex issue. If open source maintainers are saying “I told you so,” it is really about more than just open source funding.

In a blog post for OpenSSF, Brian Behlendorf argued that open source foundations must work together to prevent the next Log4Shell scramble, outlining seven points that OSS foundations could do to mitigate security risks. Among those seven points — which include security scanning, outside audits, dependency tracking, test frameworks, organization-wide security teams, and requiring projects to remove old, vulnerable code — not once was funding mentioned. Rather, Behlendorf precedes these points by saying that “Too many organizations have failed to apply raised funds or set process standards to improve their security practices, and have unwisely tilted in favor of quantity over quality of code.”

Behlendorf continues after his list of seven suggested acts with a section that boils everything down perfectly:

“None of the above practices is about paying developers more, or channeling funds directly from users of software to developers. Don’t get me wrong, open source developers and the people who support them should be paid more and appreciated more in general. However, it would be an insult to most maintainers to suggest that if you’d just slipped more money into their pockets they would have written more secure code. At the same time, it’s fair to say a tragedy-of-the-commons hits when every downstream user assumes that these practices are in place, being done and paid for by someone else.”

Behlendorf does go on to make some points about funds and fundraising, but his point is less on the lack of funding than the allocation of those funds and how they need to be focused on things like paid audits and “providing resources to move critical projects or segments of code to memory-safe languages, or fund bounties for more tests.”

Behlendorf says that, in the new year, the OpenSSF will be working to “raise the floor” for security in open source.

“The only way we do this effectively is to develop tools, guidance, and standards that make adoption by the open source community encouraged and practical rather than burdensome or bureaucratic,” he wrote. “We will be working with and making grants to other open source projects and foundations to help them improve their security game.”

Throwing more money wouldn’t miraculously get rid of bugs. Funding of OSS _is_ a problem, but it’s orthogonal to CVEs and how to avoid them. It’s good to fund OSS to thank contributors and possibly fund larger developments, but I’m annoyed by this idea that money is the solution.

— Cédric Champeau (@CedricChampeau) December 12, 2021

So, in the end, it may not be an issue of money… but also an issue of money. Money won’t magically solve open source security issues, but put in the right directions, it seems like it certainly could help.

This Week in Programming

• Vote on a Visual Studio Dashboard: For all you Visual Studio users out there, here’s your chance to make yourselves heard for a potential new feature. Senior program manager for Visual Studio Misty Hays writes in a blog post that, for three months, she read four years’ worth of user comments regarding Visual Studio setup and installation. The comments, she says, were “brutally honest” and “incredible.” In her efforts to design your Visual Studio dashboard, which will be “an experience that helps you stay on top of what’s important to your code by aggregating personalized content from all your tools and resources,” she would again like to solicit your thoughts, so head on over and let your voices be heard!
• GitHub Simplifies Getting Started with Actions: GitHub has released a new “New Workflow” experience for GitHub Actions that it says will make getting started with GitHub Actions easier. The new feature examines your repository, looks at things like programming language, builds tools, frameworks, and package managers, and then makes recommendations based on what it finds. “For example, if a repository contains a Node.js application that has been containerized, then the repository analysis will prioritize showing you both container and Node related workflows,” they explain. The new feature also offers the ability to search and filter the recommendations, which they say should “help you find the right workflow that matches your requirements faster.”

Which is it?? #TeamReGex or #TeamReJex?! Don’t hit me with that gegggegggeh pic.twitter.com/L1hQfLRe8r

— Nimay Ndolo (@nimayndolo) December 17, 2021

• The Best Time: An article hit the top of Hacker News this week that really echoed a sentiment that’s been rattling around in my brain recently — there’s never been a better time to build websites, it claims, and I couldn’t agree more. If you remember the days of yore, when you had to run your own server, reupload everything via FTP every time you made a change, build pretty much everything totally by hand, let’s just say, things have changed. “While there’s absolutely a learning curve to getting started, once you’ve got momentum, modern web development feels like having rocket boosters. The distance between idea and execution is as short as it’s ever been,” they write. And if that learning curve is daunting, which learning curves usually are, I would suggest this post as a starting point, because it lays out a number of tools that will have you up and running in no time. As he said: rocket boosters.

Some claim #opensource does not work and call #log4j the prove. But it work just fine: excellent fixes in no time. Tons of support for free. Lot’s of code reviews currently going on right now. Many people looking. For me, @TheASF just works very, very well.

— Christian Grobmeier (@grobmeier) December 21, 2021