While the OSS community has made waves in the past with vulnerability news, the wide usage of the open source Java logging library, Log4j, meant that when that vulnerability was uncovered the floodgates opened. Almost overnight, open source went from a conversation reserved for the depths of Discord channels to being something your mom might ask you about at the breakfast table.
This newfound attention highlighted the crucial interconnection between open source and closed source software components, giving rise to many misconceptions about the open source community.
It’s not amateur hour over here
With the harsh spotlight on the Log4Shell vulnerability came the grave misunderstanding that because open source was “free”, it was a community consisting of mostly amateurs. This assumption could not be further from the truth. Open source contributors are some of the most dedicated and knowledgeable programmers in the world. Some open source software is so complex it takes literal rocket scientists to build. Without highly trained experts in open source, we’d never see projects like JPLs F Prime, which is behind the flight architecture for missions to Mars.
This assumption also runs counter to one of the defining aspects of the open source community, its passion. Open source developers often join the community because they can work on more impactful projects than their regular jobs allow, leaving behind a lasting legacy.
The work done by the open source community cannot be overstated, a large portion of the internet runs on open source development.
The importance of open source contributors’ work is, however, recognized by those who are aware of their dependency on those contributions. Many employers hire open source contributors, specifically to ensure that they maintain an open source element key to their IT infrastructure.
The mischaracterization of the community aside, one benefit that came from shining a spotlight on open source was that some of that light bled onto the software supply chain as a whole. As more people paid attention to the software supply chain, a growing conversation around development standards came to the fore and alongside it, accountability.
Heavy is the head
A new focus on supply chain integrity meant a renewed focus on imparting accountability. Who is responsible for open source security? Who is to blame when vulnerabilities are discovered? Who manages disclosure? These questions have no clear answer, except for “everybody”. This means those who develop software utilizing OSS components, those who distribute software which utilizes those components, and everyone who consumes technology which utilizes those components.
The reality is that while all code has vulnerabilities, open source developers are, in general, incredibly efficient at addressing those vulnerabilities. In fact, Sonatype data has shown that 96% of downloaded OSS components with a vulnerability already have a fix.
Despite these efforts from the OSS community, there is an element of risk. Utilizing open source components means accepting responsibility for that risk. Any developer who uses open source elements must understand what that element is, where it comes from and what risk it might pose to their software’s integrity. This principle has become even more important as software supply chains have become intertwined and more complicated.
However, it is important to note that this level of risk is not something which needs to be accepted as a trade-off for using OSS components. There are methods that developers should be using to mitigate the level of risk they face.
This requires proper tooling though, the ever-increasing rate of discovery, exploitation, disclosure, and patching vulnerabilities makes manually keeping track of the context in which these are exploitable and whether an update has been made quickly impossible. Especially considering the multitude of components and projects teams work on.
The only way to know where the gaps are in your fence is to know how big a fence you have. This same principle applies to software where a Software Bill of Materials (SBOM) is a crucial step in assessing the total vulnerable surface area of your company. Simply having this information is not enough to safeguard your company, though, it must be acted upon.
Slow is smooth and smooth is fast
A pervasive myth around cybersecurity is that prioritizing security slows down development. This myth has stuck around for a while, we even researched it back in 2021 and found that the highest performers were faster than those who only focused on speed and more secure than those who only focused on being secure. Confirming that it is very possible to do both.
Now, this might seem counterintuitive until you stop and think about it. The companies only focused on speed don’t get the luxury of ignoring problems at the scale of Log4Shell. They still have to deal with those problems, but they are entirely unprepared to do so. That becomes unplanned work, immediate technical debt, and a range of other issues entirely which need additional time to resolve. This is an absolute performance killer.
In contrast, organisations that have accepted that better security means teams will move more slowly often ignore opportunities to innovate and improve speed. They’ve accepted what they believe is a realistic cost and dismissed the possibility of both.
Case closed
The salient point here is not that open source is inherently dangerous, or even that certain levels of risk must be accepted. Rather the open source community is an incredibly talented, dedicated group of individuals. The projects they share shape the backbone of many technologies we use daily. Developers need to fully understand every element of the products they build and, with automation, they can. Speed and security are not opposite approaches, they can happily coexist. By embracing this perspective, organizations can confidently navigate the open source landscape, bolstering their security stance while maintaining efficiency and agility in software development.
We’ve featured the best encryption software.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
