When it comes to developing modern business applications, open source software is everywhere. Some surveys have found that over 90% of modern applications contain open source components. Open source application development offers companies a huge advantage. Billions of freely available lines of code that can be downloaded and used for day-to-day tasks, allowing developers to focus on the unique parts of their application.

Open source has been a huge boon to app development, and we often take for granted how wonderful it is that we had all this free code available in the first place. At the same time, however, recent events such as Log4Shell, the vulnerability that affected Java’s ubiquitous Log4j logging component, have caused many companies to focus more than ever on how to improve the health and safety 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. Developed and maintained by unpaid volunteers, it has over 3,600 dependent packages in the Java language ecosystem. At the end of 2021, a vulnerability in Log4j named Log4Shell was discovered. Log4Shell is widely regarded as one of the deadliest software vulnerabilities in history. It allows attackers to remotely execute code and inject malware or take control of affected devices, which can number in the hundreds of millions.

Assessing the impact and remediation of Log4Shell has been a costly, difficult and time-consuming endeavor for many organizations. Almost all organizations use Java, which means they use Log4j. Most organizations lack a good process for managing open source across the enterprise. This means that if another Log4Shell-like vulnerability emerges, they will feel the same pain again.

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

Step 1: Familiarize yourself with your use of open source

The first step in implementing a best-in-class open source management strategy is to better understand the open source components already in use in your organization. This often involves creating a software bill of materials (SBOM) to track open source components, versions and upstream transitive dependencies in the enterprise.

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. When Log4Shell arrived, organizations with a full SBOM or a set of SBOMs covering open source use, select and patch affected applications.

Last year’s White House executive order aimed at improving the nation’s cybersecurity accelerated a chain of events that heightened the urgency of an accurate SBOM. Any organization wishing to sell to the US government should provide an SBOM showing the software components used while certifying the integrity and provenance of those components.

Step 2: Set security, maintenance, and licensing standards

In organizations without clear standards for open source licensing, maintenance, and security, developers are bogged down by the lack of consistent answers on how to integrate and manage the long-term state of open source components. As a result, they must resolve these issues themselves as they arise and may not have the specific knowledge or experience to do so effectively, or worse, they ignore them and pose a risk to the organization.

Step 3: Create a central 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 trusted repository of approved open source components that support your company’s security, maintainability and licensing. Developers can pull pre-approved components directly from the central repository when building apps. Although it requires an investment of resources to centralize approval of workarounds and update guides for open source components in the repository, it will save the organization money in the long run by creating economies of scale.

Instead of each developer verifying open source components themselves and making decisions about open source components, work that can be done multiple times by different developers for the same part, a centralized repository means that verification work only needs to be done once for the same part of those carried out throughout the organization. Over time, this repository of approved components will continue to grow, meaning more components will be pre-verified when a developer finds a need, thereby avoiding bureaucratic approval processes.

Think of the deposit as a box of pins. When you start building a repository, it can be an eight-pin box, but over time it can grow to a 64-pin box or a 264-pin box, and developers have more options while building their Accelerate development speed.

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 your use of open source, 2) defining security, maintenance, and licensing standards, and 3) creating a central repository of approved open source components, you’ll be much better positioned. to help your developers scale quickly and stay secure while harnessing the full potential of open source innovation.

This article is shared by www.itechscripts.com | A leading resource of inspired clone scripts. It offers hundreds of popular scripts that are used by thousands of small and medium enterprises.