Closing the door to open source supply chain attacks
While the OSS community has made waves in the past with news of vulnerabilities, the wide use of the open source Java logging library Log4j meant that when that vulnerability was discovered, the floodgates opened. Almost overnight, open source went from a conversation reserved for the depths of Discord channels to something your mother might ask you about at the breakfast table.
This renewed attention highlighted the crucial interconnectedness between open source and closed source software components, giving rise to many misconceptions about the open source community.
It’s not amateur hour here
With the harsh spotlight on the Log4Shell vulnerability, a serious misunderstanding emerged that because open source was “free,” it was a community made up mostly of amateurs. This assumption couldn’t be further from the truth. Open source contributors are among the most dedicated and knowledgeable programmers in the world. Some open source software is so complex that it takes literal rocket scientists to build it. Without highly trained open source experts, we would never see projects like JPL’s F Prime, which is behind the flight architecture for missions to Mars.
This assumption also goes against one of the defining aspects of the open source community: its passion. Open source developers often join the community because they can work on projects with more impact than their regular jobs allow, leaving a lasting legacy.
The work of the open source community cannot be overstated; much of the internet runs on open source development.
However, the importance of the work of open source contributors is recognized by those who are aware of their dependence on those contributions. Many employers hire open source contributors specifically to ensure they maintain an open source element essential to their IT infrastructure.
Beyond the mischaracterization of the community, one benefit of shining a spotlight on open source was that some of that light filtered into the software supply chain as a whole. As more people started paying attention to the software supply chain, a growing discussion about development standards came to the fore, along with responsibility.
The head is heavy
A new focus on supply chain integrity meant a renewed focus on accountability. Who is responsible for open source security? Who is to blame if vulnerabilities are discovered? Who controls the disclosure? These questions have no clear answer, except for “everyone”. This means those who develop software that uses OSS components, those who distribute software that uses these components, and anyone who uses technology that uses these components.
The reality is that while all code contains vulnerabilities, open source developers are generally incredibly efficient at addressing these vulnerabilities. In fact, data from Sonatype has shown that 96% of downloaded OSS components with a vulnerability already have a fix.
Despite these efforts by the OSS community, there is a risk. Using open source components means you accept responsibility for that risk. Any developer using open source elements must understand what that element is, where it comes from, and the risk it may pose to the integrity of their software. This principle has become even more important as software supply chains have become more intertwined and complex.
However, it is important to note that this level of risk is not something that should be accepted as a trade-off for using OSS components. There are methods that developers should use to limit the level of risk they face.
However, this requires the right tooling; the ever-increasing number of detection, exploitation, disclosure, and patching vulnerabilities makes manually tracking the context in which they can be exploited and whether an update is quickly impossible. Especially considering the multitude of components and projects that teams work on.
The only way to know where the holes are in your fencing is to know how big the fencing is. This same principle applies to software where a Software Bill of Materials (SBOM) is a crucial step in assessing the total vulnerable area of your company. Simply having this information is not enough to protect your business, but it does require action.
Slow is smooth and smooth is fast
A widespread myth surrounding cybersecurity is that prioritizing security slows down development. This myth has persisted for a while. We even researched it in 2021 and found that the top performers were faster than those who focused solely on speed, and safer than those who focused solely on safety. This confirms that it is entirely possible to do both.
This may seem counterintuitive until you stop and think about it. The companies that focus solely on speed don’t get the luxury of ignoring problems on the scale of Log4Shell. They still have to deal with those problems, but they are absolutely unprepared for it. That becomes unplanned work, immediate technical debt, and a host of other issues that will take additional time to resolve. This is an absolute performance killer.
Organizations that have accepted that better security means teams will move more slowly often ignore opportunities to innovate and improve speed. They have accepted what they believe to be realistic costs and rejected 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 should be accepted. Rather, the open source community is made up of an incredibly talented, dedicated group of individuals. The projects they share form the backbone of many technologies we use every day. Developers need to fully understand every element of the products they build, and with automation they can do just that. Speed and safety are not opposing approaches; they can coexist just fine. By embracing this perspective, organizations can navigate the open source landscape with confidence, strengthening their security policies while maintaining efficiency and flexibility in software development.
We recommended the best encryption software.
This article was produced as part of Ny BreakingPro’s Expert Insights channel, where we profile the best and brightest minds in today’s technology industry. The views expressed here are those of the author and are not necessarily those of Ny BreakingPro or Future plc. If you are interested in contributing, you can read more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro