Like all humans, coders aren’t perfect. They’re vulnerable, which means the software they create is vulnerable as well. This reality, combined with the persistence and evolving technical skills of threat actors, means that all software, whether it’s proprietary or built using open source libraries, is susceptible to attack.
We are all familiar with the breaches associated with Open Source. Log4j, SUNBURST, Kaseya and other large-scale attacks were at least partially attributed to open source vulnerabilities and were well-covered by industry media and analysts. The ubiquity of open source code certainly contributes to attacks like these. But clearly, as we all know from our own operations, there is most often a great deal of tension between speed and security in the development process. There’s so much pressure on getting software to market quickly —to drive revenue, meet customer expectations or maintain competitive advantage — that basic software hygiene doesn’t receive the time and attention it deserves.
A logical path to explore in the face of open source-related breaches is to resort to proprietary code. But this raises two important questions. First, is proprietary code that much more secure? After all, it’s created by humans, so it’s likely vulnerable to persistent threat actors. Secondly, is moving to proprietary code worth the time and cost tradeoffs?
Based on recent articles and social media conversations, it seems that senior leaders charged with making those kinds of decisions are still siding with open source. While the ubiquity of open source libraries presents security challenges, the answer isn’t to make the leap to proprietary code. In fact, in a Red Hat survey, titled The State of the Enterprise Open Source, 89% of 1300 technology leaders indicated they believe open source software is just as secure or even more secure than proprietary. Unsurprisingly, the survey showed their confidence is based on the availability of time-tested code and the quality and accessibility of security patches.
While there may be a bit of overreaction in the aftermath of a major attack, most software engineering and security leaders still believe in the value of open source. They also believe that a more secure path forward needs to be built on improved human behaviors — beginning with taking time to properly manage vulnerabilities and understanding the rationale for selecting specific elements of open source libraries.
These questions are critical, especially because a common practice among software engineers — who are always under pressure to move things along faster — is to incorporate highly available snippets of code or to include dependencies that have been written, tested and executed many times. And why not? If you’re under pressure to control costs and accelerate timelines, why recreate and test something that is already proven? Of course, this is where criticism of Log4j was centered: The Java-based logging framework that was used is deployed in more than 90% of all cloud environments.
These sorts of time-saving and cost-cutting practices are likely here to stay. But what can change is security leaders’ awareness and process. Dependencies are a great example. One dependency, for example, may not trigger a vulnerability, but that dependency may use another dependency that does. In other words, a coder is adding a vulnerability without knowing it. This is a common practice that is often overlooked in the race to get software to market quickly. One way to address this is to leverage a software bill of materials (SBOM), a list of all the open source and third-party components present in a codebase.
An SBOM provides a comprehensive list of all the open source and third-party components that exist in a particular codebase. It also generally includes the licenses for each component and an accounting of which versions of the components are being used, along with the patch status for each. This allows software security teams to isolate potential security or licensing risks.
The concept of an SBOM originated in the manufacturing world. A great example of its use and its value for software is the automotive industry: As a vehicle is manufactured, a bill of materials (BOM) identifies which parts were manufactured by the original equipment manufacturer (OEM) itself and which ones are from third-party suppliers. If a part is determined to be defective, the OEM can quickly determine precisely which vehicles are affected.
For software engineers, SBOMs can provide a solution for an often-overlooked problem. They allow development teams to maintain an accurate accounting of the many dependencies across their open source deployments. Like in the automotive example, if a security vulnerability is discovered, software engineers can search their databases and determines precisely which software products are affected. This allows for a faster plan of action when a patch is needed — or if third-party vendors need to be engaged for their elements of the code.
Of course, using SBOMs doesn’t fix everything — they’re just one piece of a broader strategy. For example, the concept works great when a product is first launched into the field. But over time, products change as updates and patches are deployed. It would be difficult for a software company to issue a new SBOM every time a vulnerability was patched.
According to the Red Hat survey, adopting practices like SBOMs and generally improving software hygiene is going to become more important. Respondents said proprietary code will drop from 45% to 37% across their internal infrastructures and in their products, indicating that larger enterprises will reduce the use of proprietary software in their organizations. At the same time, the use of enterprise open source is expected to increase from 29% to 34% — and community-based open source is projected to jump from 21% to 24%.
So why the jump? Part of it can be attributed to growing confidence in the security of enterprise and community open source. According to an annual Veracode study, 35% of the libraries in enterprise open source applications were afflicted with security vulnerabilities five years ago. The most recent Veracode study shows that number is closer to 10% today. This decrease, it seems, was driven more by human behaviors — and general vulnerability awareness — than any purely technical improvements.
At the 2022 Open Source Software Security Summit II, a conference hosted by the Linux Foundation and the Open Source Software Security Foundation (OpenSSF), the largest cloud service providers (CSPs) and other tech companies have said they are planning to spend approximately $30 million to improve security and mitigate vulnerabilities. The spending commitment was accompanied by a 10-point plan to improve open source security.
One of the key points of that plan focuses on the use of SBOMs to gain visibility into the software that comprises tech stacks. In addition to improving vulnerability detection and remediation, the plan outlines steps to accelerate path response times. Also, the plan outlines the need for security education for people throughout the open source community and the eventual elimination of non-memory safe programming languages, such as C++ and COBOL.
Ultimately, addressing the vulnerability of open source is going to be a group effort. Organizations of all sizes will have to implement a security-first approach to the use of open source code. Our global community of tech firms will likely have to band together to create some baseline standards for minimum security requirements. Government organizations will have to be part of the solution, too, by working with enterprises and the broader open-source community to create testing and certification guidelines — and possibly creating impartial third-party certifying bodies.
Open source will remain an important part of our lives for at least the next several years. The cost, convenience and performance it delivers is simply too compelling. It’s up to us to come together to improve the human behaviors and shared processes that surround it.