Webinar highlights: In the open source software security predictions webinar this week, our team of expert prognosticators sees 2024 bringing us open source contributors and users fighting back against corporate exploitation of open source, and returning to free software roots. The increase in sometimes-conflicting government mandates around the world may create a GDPR-like moment for open source security. We’ll also see AI give a “Taylor Swift bump” to open source and security, and we’ll see a rise in organizations focusing on vulnerability prevention in addition to vulnerability remediation.

With 2023 in their rearview mirrors, Tidelift co-founders Donald Fischer and Luis Villa, RedMonk analyst Kelly Fitzpatrick, npm package maintainer Jordan Harband, and Fannie Mae OSPO strategist Brittany Istenes got together this week in a Tidelift webinar to look ahead to the new year and offer their insights on what we can expect in open source software supply chain security in 2024. Below are the key takeaways from predictions you won’t want to miss. To watch the webinar on-demand, you can follow this link.

Revisiting 2023’s predictions

Open source maintainers push back

Last year, Tidelift predicted that open source maintainers would, rightfully, push back on the growing requirements coming from governments and industries, deeming them “unfunded mandates.” 

In the 2023 Tidelift state of the open source maintainer report, it was stated almost half of all open source maintainers are solo maintainers. Not only can this be lonely and stressful for many, but it also means if for whatever reason a maintainer needs to step away, the project goes on unmaintained—leaving it and any other package that depends on it vulnerable. Open source maintainer Jordan Harband shared a story of where he adopted a popular open source project from a maintainer who no longer had the bandwidth to maintain his projects that he had been maintaining for well over a decade. When the maintainer was asked to adopt two-factor authentication (2FA) requirements, he decided to leave his project rather than comply. 

“This is such a tough thing to talk about because it sounds like you’re saying, ‘this is a bad person, they didn’t want to do two-factor authentication.’ And that’s not the case. These people were doing something good for all of us and this just happened to be the straw that breaks the camel’s back,” Luis added. 

Some additional context from our 2023 maintainer report: When we asked maintainers about which industry standards they were aware of, over half responded that they weren’t aware of any. Furthermore, when we asked those who were aware of standards if they planned to align to them, 39% said they have no plans and 19% were unsure. Without more support, it’s not easy taking on more tasks.

Jordan offered a maintainer perspective, “Certainly you could look at any one specific thing like a maintainer reacting to two-factor authentication and say, ‘that’s ridiculous.’ But everyone has an individual bar and I think that’s the main issue here—open source is being treated as if it should be a business: it should have constancy, reliability, security, dependability, and we should be able to make asks of it. And at the same time, it’s being treated as an individual's hobbies and passion projects. Where no one has to pay anything and you get to do whatever you want. And those two things are somewhat incompatible, and the effort required to blend them together has not quite materialized yet.” 

Software bill of materials (SBOMs) may not be the silver bullet 

SBOMs are the ingredients list of a software application, helping organizations better understand what their applications are composed of, especially important for organizations that consume a lot of open source software. It’s been a hot topic for a few years, building momentum in 2023 as more government cybersecurity requirements call out their importance. 

To kick off the conversation, Donald provided his observations of the lifecycle of the SBOM in 2023: 

“[In 2023] I witnessed a lot of organizations that are big consumers of open source software understanding that SBOMs are a good starting point, but you’re seeing people ask, ‘now what? What do I do with this?’ Specifically, the thing organizations are looking for is how to connect this activity of building this list of ingredients to actual business value, to reduce business risk, etc. It’s been revealed that making this list is a good starting point, but once you do that, you need to start doing something with this list. A minimum bar to hit would be to help filter out the open source components or versions of open source components that are known to be vulnerable. A lot of organizations started doing this, but they’ve also started to think ahead and ask how they can look forward and try to select applications that are known to be better supported in the future, that have more health and resilience—which is where I think the SBOM question is headed in 2024.” 

When it comes to knowing more about the open source software being used in an organization, that level of detail often requires open source maintainers providing details about the security and maintenance practices. However, with more boxes needing to be checked with government and industry requirements ever-growing, it’s not an easy task for maintainers, especially without proper incentives or support. Jordan shared his thoughts from the maintainer point of view: 

“In terms of a supply chain, if someone finds contamination in a lettuce farm, how does the person who gets a salad at a restaurant know if they have to worry about it or not? Because that’s a chain of business, it’s possible to use legislation and market pressure to get that information so when you order that salad, you can ask the waiter how they know if the salad is safe. Theoretically, they could bring over a food SBOM. That’s something I could see as feasible. Though with open source software, the economic incentives stop outside of the businesses, the open source maintainers rarely have those economic incentives, and government regulation is not everyone’s favorite way of solving problems and it’s also not complete.” 

2024 open source security predictions

Corporate exploitation of open source causes contributors and users to fight back

As the conversation shifted towards looking ahead, Donald brought up his first prediction: an unexpected revival of originalist free software principles. He envisions that in 2024 we’ll be leaving behind a time period in which the principles underlying the open source movement took a back seat to commerce. Open source contributors and users will rediscover open source’s roots in the free software movement and start fighting back against commercially controlled projects bending and breaking open source principles in search of profits. And by going back to the origins of the free software movement, organizations will begin to once again reap the benefits of the model as it returns stronger than ever.

Kelly shared her observations, “In the tech industry we see pendulum swings all of the time, and this is the potential moment of the pendulum swinging the other way in terms of people really pushing for a clarifying use of open source that isn’t being obfuscated or confused by these commercial interests. We have businesses that are re-licensing and calling things an open source license. I love the idea of things going back to free software. I don’t know if everybody who uses or creates open source will be invested enough to go back to that, but I do think there is going to be this push to mean open source when we say open source.”

More global government mandates create GDPR-like moment for open source security

As new government security requirements trickle in (such as those required under M-22-18 and White House Executive Order 14028 in the US and the Cyber Resilience Act in the EU), Luis predicts that they’ll bring confusion for organizations and open source maintainers. With a lack of clear direction and conflicting incentives and penalties, they’ll actually slow down progress toward improving security outcomes intended to be served by the proposed regulations.

Luis introduced the topic, explaining why the open source supply chain isn’t necessarily like other supply chains: 

“2023 was all about realizing that this stuff [open source] is actually super central to our entire economy and we better secure it. However, we’re not really sure how this is going to work. The EU as of November or December were talking about 40-some new standards that are going to have to be implemented that software providers are going to have to comply with. Some of those are going to come with assumptions from industries that just don’t work—ideas from a pharmaceutical supply chain or an automotive supply chain, it turns out when you start trying to apply them to open source, it surfaces assumptions that break. Including, critically, finances flowing down, whereas regulation can flow down pretty straightforwardly. We’re making up a new model for this mismatch because there aren’t contracts in place, there isn’t money flowing. And we don’t yet know how this is going to work out.” 

Jordan proposed another solution—indirect legislation: “With GDPR, the people that had to comply were the application developers and they’re the ones, theoretically, making the money. There were few things that had to be passed down the supply chain. The other big difference is that, at some point down the supply chain, the money stops flowing and there’s no contract. That’s not something you can fix with direct legislation. If the government passed a law for all volunteers to get a permit first, what’s going to happen to volunteering? The answer is it’s either going to happen without a permit or people are going to stop volunteering. This requires indirect legislation. The people that need to do something need to be the ones that are benefiting from it, which are the people making the money. You can put regulation on them, requiring them to invest time or money in the people that aren’t otherwise benefiting so they do benefit. I think that’s the only type of path that’s viable here.” 

Why should maintainers do this work? 

An attendee raised a question during the discussion, asking: why are we tasking maintainers with this work? Shouldn’t the companies using open source lead the charge for securing their software. 

Brittany stepped in, “Yes, I agree, and I think that we’re asking these specific mandates and asking our maintainers to do all of these specific things from an enterprise perspective. We realized SBOMs were not complete silver bullets because there are limitations in what we are looking towards. We’re asking for all of these different sorts of reports such as runtimes—we’re looking for a complete end-to-end compliance view that we’re not getting, and then we’re asking our maintainers and our developers to decipher all of this information. If we want end-to-end compliance with our SBOMs, we need to be able to develop further within these reports. We need to have this holistic view that leadership can point to, that’s automatically baked into our applications. We have our software bills of materials, but then we have events like Log4Shell and we have to work to find where it is. If I’m a maintainer like Jordan, I have to look through my entire package to find this.”

AI and open source security

Kelly related this as it stands in AI, “One thing that has not really translated into the world at large, yet, is what open source is. Security pops out when we have incidents like Log4Shell, things that people hear about. SBOMs is something that hasn’t made that jump into its cultural moment. One of my predictions is that generative AI will have that Taylor Swift bump of recognition of things for open source and security—maybe there’s a place where those intersect and we have people saying, "oh maybe we should have budgets for things like this.”

Jordan added, “My hope is that in 2024 we have collectively realized that AI is a useful tool for surfacing patterns, summarizing things, and suggesting directions, but that it is a vastly different thing from being a good tool to get correct answers without a human being involved. But there’s a lot of value you can get from it if you understand the limitations, if you’re an expert in the domain, or if it’s trained in a very specialized way. My hope is that we’ll slow down when it comes to AI—just have more appropriate context as we use these tools.” 

Donald offered his thoughts on the reverse: the impact of open source software security on how people approach AI, “AI has a supply chain of its own that includes open source software, recursively. Maybe the things that we just figured out over the last twenty years with open source software, let’s pay attention to those learnings and not wait twenty years to figure out the landscape of AI.” 

An increased focus on vulnerability prevention vs. vulnerability identification and remediation

2023 and 2022 saw a lot of conversation around vulnerability identification and remediation. With events like Log4Shell being costly and time consuming, the industry knew we needed to find better ways to remediate. But what about working to prevent these zero-day vulnerabilities  in the first place? Our panel predicted that in 2024 the conversation will begin to shift from vulnerability remediation to vulnerability prevention.

Brittany provided her outlook, “The vulnerabilities are identified now—amazing! But oh no, I need to identify them now. The CVE scores are high. All of these reports are coming out. Your hair has been on fire for all of 2023 especially in the remediation world. No one wants to do that again. We have to think smarter and not work as hard. We noticed a huge skills gap, and one of the ways we can solve this is through education and doing things together. Security and technology do not need to work against each other. We need to create special interest groups, where we’re able to get these subject matter experts together to problem solve. When you get teams that work together, such as in an InnerSource model, you’re going to streamline development—which makes our technologists happier. But if we keep getting mandates and deadlines…it’s stressful.” 

And there you have it! These are the predictions of 2024. We’re eager to see what the year brings and we hope it involves improvements to open source security that include supporting and looking out for the open source maintainers behind the hundreds of packages we rely on. To hear the entire discussion, you can follow this link to watch the webinar on-demand. To learn more about Tidelift and how we’re working with (and paying!) open source maintainers to help provide unique, human-validated open source data for organizations to quickly and safely build their applications, you can learn more about our validated open source package intelligence and book a demo today.