As part of Solutions Review’s Premium Content Series—a collection of contributed columns written by industry experts in maturing software categories—Donald Fischer, the co-founder and CEO of Tidelift, shares some insights on improving the health and security of an open-source software supply chain.
When it comes to modern enterprise application development, open-source software is everywhere. Some surveys have found that more than 90% of modern applications contain open-source components and for a good reason. Developing applications with open-source gives organizations an enormous head start—billions of lines of freely available code that can be downloaded and used to accomplish everyday tasks, allowing developers to focus on the pieces unique to their app.
Open-source has been an enormous gift to application development, and we often take for granted what a marvel it is that we even have all of this free code available to use. Yet, at the same time, recent events like Log4Shell, the vulnerability that impacted the ubiquitous Java logging component Log4j, have many organizations more focused than ever on how to improve the health and security of their open-source software supply chain.
What is Log4Shell, and why was it so dangerous?
Log4j is a Java logging component that has been in use for over 20 years. It was developed and maintained by unpaid volunteers and has over 3,600 dependent packages in the Java language ecosystem. In late 2021, a vulnerability was discovered in Log4j, nicknamed Log4Shell. Log4Shell is widely considered among the most severe software vulnerabilities in history. It allows attackers to execute code remotely and insert malware or take control of impacted devices, potentially numbering in the hundreds of millions.
Assessing the impact of and remediating Log4Shell was and, for many organizations, continues to be an expensive, challenging, and time-consuming effort. First, Log4j is ubiquitous—almost every organization uses Java, which means they use Log4j. Second, most organizations don’t have a good process for managing open-source across the enterprise. This means that when another Log4Shell-style vulnerability emerges, they’ll experience this same pain again.
3 Tips to Improve Your Open-Source Software Supply Chain’s Health and Security
So how can organizations prepare for the next vulnerability and more effectively manage the health and security of their open-source software supply chain? These three steps provide a good start.
Step 1: Understand your open-source usage
The first step to implementing a best-in-class strategy for managing open-source is to get better visibility into the open-source components already in use within your organization. This often involves creating a software bill of materials (SBOM) to track open-source components, versions, and upstream transitive dependencies (additional features being called by the components you are using) across the organization.
This SBOM can’t just be a static document because components and versions in use are constantly changing as new versions become available, as security vulnerabilities are patched, etc. When Log4Shell happened, organizations with a comprehensive SBOM or set of SBOMs documenting open-source usage could triage and remediate impacted applications.
Last year’s White House Executive Order on Improving the Nation’s Cybersecurity accelerated a chain of events increasing the urgency around maintaining accurate SBOMs. In essence, it stated that any organization wanting to sell to the US Government would have to provide an SBOM showing the software components in use while simultaneously attesting to the integrity and provenance of these components.
Step 2: Define security, maintenance, and licensing standards
Once your organization has a sense for the open-source already in use today, it can turn attention to defining a set of standards and policies around open-source usage. What policies or procedures should you use when bringing new components into the organization? Do you have different levels of security tolerance for internet-facing applications vs. internal? Are there specific open-source licenses or categories of licenses that are not acceptable to your legal team?
In organizations without clear standards around open-source security, maintenance, and licensing, developers are slowed down because they don’t have consistent answers regarding how to bring in and manage the long-term health of open-source components. This leaves them to either address these issues on their own as they come up—which they may not have the specific knowledge or experience to do effectively—or worse, ignore them and create risk for the organization.
Step 3: Build a centralized repository of approved open-source components
The best way to ensure your developers can move fast and stay safe when building applications with open-source technology is to create a trusted repository of approved open-source components that meet your organization’s security, maintenance, and licensing standards. Developers can pull pre-vetted components directly from the centralized repository when building applications. While this requires a resource investment to centralize the workaround approving and updating guidance for open-source components in the repository, it will save the organization money in the long term because it creates an economy of scale. How?
Rather than each developer vetting and making decisions on open-source components on their own, work that may be done for the same piece several times by different developers, a centralized repository means that vetting work is done once for the entire organization. Over time, this repository of approved components will continue to grow, which means more components will be pre-vetted when a developer finds the need for them, allowing them to avoid bureaucratic approval processes.
Think of the repository as a box of crayons. When you start building a repository, it may be a box with eight crayons, but over time, it can grow to be the 64 crayon box or the 264 crayon box, and the developers will have more choice while accelerating their development pace.
A More Healthy and Secure Open-Source Software Supply Chain
The best way to improve the health and security of the open-source software supply chain is systematically over time. But once your organization has gone through the process of 1) understanding their open-source usage, 2) defining security, maintenance, and licensing standards, and 3) building a centralized repository of approved open-source components, they’ll be much better positioned to help ensure their developers are moving fast and staying safe, while also taking advantage of the full innovative potential of open-source at the same time.