3 Tips for Improving the Health and Safety of the Open Source Software Supply Chain

0

As part of Solutions Review’s Premium Content Series, a collection of columns written by industry experts in maturing software categories, Donald Fischer, co-founder and CEO of rising tideshares some ideas on improving the health and safety of an open source software supply chain.

When it comes to modern enterprise application development, open source software is everywhere. Some surveys have revealed that more than 90% of modern applications contain open-source components and for good reason. Developing apps with open source gives organizations a huge head start: billions of freely available lines of code that can be downloaded and used to accomplish everyday tasks, allowing developers to focus on the clean stuff. to their application.

Open source has been a huge gift to app development, and we often take for granted how wonderful it is that we even have all 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 focusing more 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 used for over 20 years. It was developed and maintained by unpaid volunteers and has over 3,600 dependent packages in the Java language ecosystem. At the end of 2021, a vulnerability was discovered in Log4j, dubbed Log4Shell. Log4Shell is widely regarded as one of the most serious software vulnerabilities in history. It allows attackers to remotely execute code and insert malware or take control of affected devices, which potentially number in the hundreds of millions.

Assessing the impact and remediation of Log4Shell was and for many organizations continues to be an expensive, difficult and time-consuming effort. First, Log4j is ubiquitous – almost all organizations use Java, which means they use Log4j. Second, most organizations lack a good process for managing open source across the enterprise. This means that when another Log4Shell-like vulnerability appears, they will feel the same pain again.

3 tips to improve the health and safety of your open source software supply chain


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 are a good start.

Step 1: Understand your use of open source

The first step in implementing a leading strategy for open source management is to gain 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 functionality being called by the components you use) across the organization.

This SBOM cannot simply be a static document as the components and versions used are constantly changing as new versions become available, security vulnerabilities are patched, etc. use could sort out and fix affected applications.

Last years White House Executive Order on Improving the Nation’s Cybersecurity accelerated a chain of events increasing the urgency of maintaining accurate SBOMs. In essence, he said that any organization wishing to sell to the US government should provide an SBOM indicating the software components used while simultaneously attesting to the integrity and provenance of those components.

Step 2: Set security, maintenance, and licensing standards

Once your organization understands the open source already in use today, it can focus on defining a set of standards and policies around the use of open source. What policies or procedures should you use when introducing new components to the organization? Do you have different levels of security tolerance for web-accessible applications versus internal applications? 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 held back because they don’t have consistent answers on how to integrate and manage the long-term health of open source components. This leaves them to either solve these problems on their own as they arise – which they may not have the specific knowledge or experience to do effectively – or worse, ignore them and create a risk to the organization.

Step 3: Create a centralized repository of trusted open source components

The best way to ensure that your developers can move quickly and stay safe when building applications with open source technology is to create a reliable repository of approved open source components that meet security, maintainability, and maintenance standards. license from your organization. Developers can pull pre-approved components directly from the centralized repository when building apps. Although it requires an investment of resources to centralize the workaround approving and updating guidance for open source components in the repository, it will save the organization money in the long run as it creates a economy of scale. How? ‘Or’ What?

Rather than each developer verifying and making decisions about open source components themselves, work that can be done multiple times for the same part by different developers, a centralized repository means that verification work is done only once for the same part. whole organization. Over time, this repository of approved components will continue to grow, which means that more components will be pre-verified when a developer finds the need, allowing them to avoid bureaucratic approval processes.

Think of the repository as a box of pencils. When you start creating a repository, it might be an eight-pencil box, but over time it can become the 64-pencil box or the 264-pencil box, and developers will have more choices while accelerating their rate of development.

A healthier and more secure open source software supply chain

The best way to improve the health and safety of the open source software supply chain is systematically over time. But once your organization has gone through the process of 1) understanding its open source usage, 2) defining security, maintenance, and licensing standards, and 3) creating a centralized repository of approved open source components, they’ll be much better positioned to help ensure their developers scale quickly and stay secure, while leveraging the full innovation potential of open-source at the same time.


Donald Fischer
Last posts by Donald Fischer (see everything)
Share.

Comments are closed.