Securing open source software is a team sport

Two years ago, the joint government-private sector response to the Log4j vulnerability that spawned 800,000 attacks worldwide led to the Enduring Security Framework for federal agencies adopting open source software. During that time of crisis, the potential benefits of true public-private partnerships and cooperation were on full display.  

Representatives from several technology trade associations and interest groups, private enterprises, and federal government agencies convened an effort to establish standards and norms around the secure development and use of information technologies — including, of course, OSS and components. And in the short term the combined efforts of these groups — including agencies like the Cybersecurity and Infrastructure Security Agency, NGOs and advocacy groups like the Linux Foundation and private sector participants such as Amazon, Akamai and Google — were nominally successful, leading to a set of guidelines for OSS security that federal agencies must follow when procuring or producing new software. 

However, that initial surge of cross-sector zeal has since dwindled, and there’s still a great deal of work to be done. While some legislative initiatives have cropped up in the U.S. and EU, the most potent and promising outcome of the post-Log4j  moment — collaboration between the public and private sectors — has cooled off considerably. And in order to ensure the continued viability of OSS and the security of our public and private sectors’ information technology infrastructure, efforts towards cross-sector partnerships and collaboration must be renewed.

OSS adoption skyrockets amid enduring security challenges

Despite the shake-up caused by Log4j and the like, OSS adoption shows no signs of slowing. Most recent estimates put the share of businesses using open source software in their day-to-day operations at over 78% today. Meanwhile, some 96% of all software (proprietary included) includes at least one open source component. 

Nonetheless, the open source software landscape as a whole — including both applications and the far more ubiquitous components — remains broadly unregulated. That isn’t to say that all OSS is inherently vulnerable or in need of regulation. On the contrary, it is primarily a matter of its ubiquity, especially that of open source components, that make it such a central security concern. There are those who argue OSS poses inherent risks due to the transparency of its source code. The truth is, however, the overwhelming majority of actual security incidents are the direct result of simple negligence. 

Look no further than the continued proliferation of attacks leveraging well-known and years-old SQL injection vulnerabilities. While organizations continue to see untold damage as a result of these, in almost all cases,  these crises could have been averted if the end-user organization had patched/updated their software. In fact, the problem has grown so egregious that the FBI and CISA were recently compelled to release a joint Secure by Design Alert to urge manufacturers to finally rid the software landscape of these flaws, which the agencies deemed “unforgivable” in the aforementioned alert, given how well-known and easily-addressed they are. 

Why public-private partnerships make sense

Unfortunately, the initial enthusiasm for collaborative action seen in the wake of the Log4j disaster was short-lived. This isn’t to dismiss or devalue the victories of the ESF Software Supply Chain Working Panel, or the White House’s cybersecurity executive order, which established new requirements to secure the federal government’s software supply chain. 

While these are undeniably steps in the right direction, both actions suffer from the same two fundamental issues limiting much of the world’s efforts — limited reach and a lack of teeth. While government agencies undoubtedly require guidelines, the bulk of use and exploitation of these technologies resides in the private sector. 

And yet, years on from the Log4j debacle, the absence of cross-sector collaboration has resulted in a landscape without any policies or legislation that in any way mandate the behaviors of commercial enterprises in their use of OSS. Stern warnings from CISA and the FBI have their place in the regulatory landscape. However, what is truly needed today are practical policies that promote the safe, efficient use of OSS, while stimulating innovation designed to mitigate the risks associated with the exploitation of OSS vulnerabilities.

There’s a paradox at play that has engulfed open source software: despite its prevalence across the business landscape and the resulting value it injects into the global economy, its decentralized and free nature can lead to both an underappreciation of that value and an underinvestment in its growth and security. There’s something distinctly human about the notion of unfettered access to a seemingly unlimited resource obviating any sense of individual responsibility for the maintenance of that resource. It’s as if joint ownership of an asset equates to no ownership at all. 

However, as has always been the case, as technology becomes more advanced the repercussions of its abuse and exploitation become all the more significant. One needn’t look any further than the burgeoning field of artificial intelligence — and the rapidly growing presence of open source AI models — to recognize that the stakes associated with open source security only stand to raise. Ideally, open source projects are developed as community projects, as opposed to a single individual or single vendor. Being community lead allows the responsibility and cost of maintaining to be balanced and shared. However, for those proprietary outfits out there openly commercializing software that contains mostly open source components, there is something to be said for community action and the need for reciprocity to those volunteering their efforts. Recently, a grassroots project called The Open Source Pledge  has sprouted up to implore such organizations to do exactly that — pledging monetary contributions to maintainers as a way of “giving back” for their labor. 

We can’t afford the status quo of selective underinvestment for much longer. Federal regulation over the practices of private enterprises is coming. And rather than waiting for the discovery of the next critical vulnerability in OSS to kick off another ad hoc public-private partnership, the open source community should claim seats at the government’s table now to proactively map out, monitor, and modify a set of best practices for securing open source projects. If the open source community proactively collaborates with CISA and NIST now, chances are greater that the OS community will have the desired level of influence over the inevitable legislation coming our way. And isn’t self-determination what each of us really wants?