At the start of April, we marked ten years since the disclosure of the Heartbleed vulnerability, and looked at what lessons we had learned from its exposure.

Now as we near the end of the month, I wanted to get an idea of how much of an impact it had on the world of open source in particular. In the initial research I spoke with Phil Odence, general manager of the Black Duck Audit Business at Synosys, who said there is now more use of open source, and while Heartbleed was “a wake up call for the use of open source,” anyone using it up to 2014 were focused on components which were often not licensed.

After Heartbleed was discovered, he said it was determined by industry that there needed to be better attention given to components such as OpenSSL, as “it was being run by three old guys in a garage, these were the maintainers upon which millions of web servers were dependent.”

This grew into the Open Source Security Foundation (OpenSSF), and Odence said that this is an example of the change in the software world from Heartbleed’s discovery.

Where Were You When?

SC UK was able to connect with the OpenSSF’s general manager Omkhar Arasaratnam, who calls Heartbleed a ‘where were you when’ moment, who was on vacation from his role as a security architect at TD Bank at the time. However via a vendor they used, they were able to get embargoed information on the vulnerability and deal with it in advance.

In his role for around a year, I asked Arasaratnam if he feels that open source is getting the love and attention that it probably wasn't getting ten years ago. He feels it is getting the attention, but is it enough?

“I think in many instances, the reason that not enough time, effort, and resources are spent on open source is that it is almost economically opaque,” he says, explaining that if you were to build out a cryptographic library like OpenSSL and consider the ongoing maintenance, how worthy of your time is that versus installing OpenSSL.

Arasaratnam says that level of economic opacity “means that people don't realise what the true cost of maintenance is when it comes to some open source packages.”

The other challenge for open source is that it is run by people “with different incentives with different priorities, with different desires.” He puts these people into four different categories:

Group 1- Folks working in big organisations who are paid full time, get the fulfilment they need and are quite happy doing what they do. However some sub-segments of the community may say they are a “tool of a big corporation”, rather than truly a member of the community.

Group 2 - People who are maintainers for popular packages, and love to do this full time. They are not afforded the privilege of this being their full-time job, as they have a full-time job elsewhere and they're doing this as a hobby, and if somebody were to pay them a salary to do this full time, they would love to do it.

Group 3 - These are people who are quite happy to continue to do this as a hobby, but they would really like it if people would contribute more upstream.”We''ve seen a number of cases in which unnamed multi-trillion dollar corporations will demand features or bug fixes from volunteer projects with almost laughable arrogance.”

Group 4 - The class of maintainer where developing this tool was a hobby, and how it got inserted into every router on the internet is bewildering to them, where packages have grown “well beyond their original intended distribution.”

Arasaratnam says when it comes to answering the question of ‘are we doing enough for the community’, we should first understand what the community needs for it to be sustainable, and that we can determine whether enough is being done in each of those four kind of scenarios - or if we need to do something different.

Financial Investment in Open Source

He also says that the challenge of financial investment into these projects “pollutes the purity of this being open source.” There is also a concern about “open source washing” where something looks like open source - but for some reason there is only one company contributing to it - and there's questions in terms of whether that's a benefit or a deficit to the community.

“Among the community there are those that strongly oppose that kind of commercial interest and find it abhorrent, there are others that welcome it because we do live in a capitalist society and we do need money in order to be able to keep lights on and such things,” he says.

Open source maintenance has three major constituents: private and public sectors, and the community, “but It's riding on this economically opaque contribution from a series of maintainers who've never met.”

He used the analogy of taking water from a lake and not replenishing the resource. “If you come across a creek and you take a sip of water for your own consumption, that's one thing. If you're building a business off of bottling that water, it's a bit naive to think that that resource is going to be around forever.” 

This means open source requires working with the private sector to help them understand some of the ways they can contribute to making open source more sustainable .

Lessons Learned

So ten years on, are we better at dealing with issues with these lessons learned? Arasaratnam says a recent example is the xz backdoor, CVE-2024-3094. He says that was a slightly different issue in that it appeared to be caused by intentionally malicious threat actor, rather than an accidental bug that appeared in the software,

“Nonetheless.I think it illustrates a very interesting situation that there's two different, but correlated, capabilities within open source: security and trust.” He explains that with security, all code should have to pass the same security tests.

With trust, “if we follow the kind of role hierarchy within open source you have consumers, you have contributors, and you have maintainers - and the maintainers have absolute authority over new code that gets merged in.”

He says that we count on the maintainer to not only inspect new pull requests in order to determine if the submitted code is architecturally aligned with the direction of the project, and whether it's conforming with coding and style guidelines for how the source code should be written, and whether the submitted code is of good intent, and is secure.

In the case of xz, a maintainer was physically exhausted from the work,.and was the victim of a social engineering attack

He says: “It is different than Heartbleed, but it is still something that indicates that we have to be. aware of our surroundings when it comes to open source.”

It is clear that the security of open source is fragile, but also in the safe hands of OpenSSF. What we have learned from the xz incident though is that new instances can happen in open source tools, especially where we are so reliant upon its functions, and investment has to come in all forms to ensure those issues are reduced.

Dan Raywood Senior Editor SC Media UK

Dan Raywood is a seasoned B2B journalist with over 20 years of experience, specializing in cybersecurity for the past 15 years. He has extensively covered topics from Advanced Persistent Threats and nation-state hackers to major data breaches and regulatory changes. Outside work, Dan enjoys supporting Tottenham Hotspur, managing mischievous cats, and sampling craft beers.