Heartbleed was more than 7 years ago. This year, the new Heartbleed is Log4Shell, which is in no way less severe than Heartbleed. I lost several hours of work due to Log4Shell, and it cost way more for many of my colleagues. Will such ridiculous flaws keep being revealed ad vitam æternam?

Following Heartbleed, myself and others started a reflection which would result in the CII, which is being replaced by the OpenSSF. Last time I blogged about OpenSSF, it wasn't even one year old, and was still incubating. After a year and a half, how close was OpenSSF to avoiding Log4Shell?

The short answer is far. The practical part of OpenSSF, Project Alpha-Omega, has secured 5M USD which can partially be invested in identifying vulnerabilities. While this amount is significant, it is obviously far from being enough to secure even the critical open source components in a reactionary mode. The project's current scope is to get involved in the approximately 100 most critical open source components. Is Log4j part of these?

With the high number of components, that's a hard question to answer. And the OpenSSF's answer to these questions are based on the Open Source Project Criticality Score, which estimates Log4j as the 2543th most critical open source project, with a criticality score of 0.6231. Are there really 2542 projects more critical than Log4j? That might still not be a trivial question, but what is clear is that OpenSSF's ordering makes no sense. According to the list, the 355th most important is Zcash. If you don't know Zcash, you're excused; it is ‘an implementation of the "Zerocash" protocol’. An exception? Way above that, we find at #43 the Bitcoin Core project, which is dedicated to an alternative "currency". Zcash and Bitcoin Core respectively have a criticality score of 0.75 and 0.87. 2024 Update: I removed the link to the list, since it is a moving target and now points to a whopping 100 MB file. The scores have changed widely since this was posted, but remain unusably unreliable.

In short, OpenSSF is mostly at the same point as it was last year: incubating. There are positive aspects:

• OpenSSF recognizes its scoring is immature (it's qualified as beta)
• the Foundation has managed to raise significant funding.

But turning that funding and further resources into results will take a long time. OpenSSF's reaction to Log4Shell is interesting, but when we're still at an early stage of prioritization, we should refrain from wearing rose-colored glasses and acknowledge it will take more years to see real results.

So, here's hoping for a 2025 and beyond with fewer fires

Update

Brian Behlendorf's article has sparked controversy. I agree with Behlendorf in the sense that increasing the general funding of an open source project would be far from an efficient way to specifically help secure it. But the controversy is understandable in the sense that the way Behlendorf describes his stance is exaggerated:

Any senior programmer knows that the only perfect code is the one which doesn't exist. No program can be perfectly functional, performant and secure. Security is one quality, and as for any quality, aiming for (guaranteed) perfection would require infinite resources. All professional senior programmers have at some point been under pressure to deliver, which causes us at times to ship without being entirely convinced by quality, and we know very well that security is one of the first aspects many neglect under too much pressure.

More money/resources definitely helps with all qualities, including security.