How to Ease the Pain Points of Managing Open Source Software

Managing open source software doesn’t need to be painful. Just as with health, a preventive care approach can help strengthen the program overall and avoid emergencies. Alex Rybak, senior director of product management at Revenera, provides questions that software companies can answer to check the health of their programs. 

How do you rate your pain on a scale from 0 to 10?

Chances are, a medical professional has asked that question in a health check scenario. For an acute issue that lands you in the emergency room, there’s a good chance that you’re rating a sharp or throbbing pain up around seven or higher. If you’re at your primary care physician’s office for help with a sore throat, maybe that pain is just a dull ache – a two. If you have no pain at all to report during a preventive care visit, zero.  

When it comes to the pain potentially associated with managing an open source software (OSS) program, many software companies can respond to a similar pain scale. When a vulnerability is discovered, there’s a good chance your team feels shooting pains, particularly if you’re scrambling to determine if you’re impacted and where. But the process of software composition analysis (SCA) is about preventing disruption—essentially easing the discomfort of tracking and maintaining all of the components used in your software, mitigating risks and exposures presented by OSS and third-party components, and remediating discovered issues as painlessly as possible. 

Your physician aims for zero pain. Your open source management efforts should aim for the lowest score possible. Here are a few ways SCA can help streamline your programs and ease common maladies. 

Software Composition Analysis as Preventive Care

Everything about SCA is about prevention: heading off vulnerabilities and security risks, managing license compliance, averting disruption to your software development life cycle (SDLC), and protecting the business’s ability to sell innovative products. The need for SCA has only grown in recent years, particularly in light of the developing US guidelines around securing the software supply chain. One of the key elements of these guidelines is producing and maintaining a complete and accurate software bill of materials (SBOM). An SBOM allows you to catalog the SBOM parts (ingredients) in the applications your organization builds and/or enterprise applications your application uses to be able to assess the impact of a newly reported security vulnerability across your organization. 

Ultimately, this focus on risk management and risk avoidance can help drive greater return on investment (ROI), whether that investment was in time, resources, staffing, budget, or reduced litigation costs. As SCA programs mature, evaluating metrics can help ensure that you’re taking appropriate preventive care—of your software and your business overall. 

See More: Top 10 Open Source Cybersecurity Tools for Businesses

Check Up on Your Own Program

As I’ve written before, there are multiple benefits to taking a proactive approach, no matter where you are in the software supply chain. Part of the process is to get a baseline of how well your team is doing today. To avoid the acute pain and disruption associated with discovering a vulnerability in your code, pose the following questions to your teams to see how you stack up. 

Perhaps some of these questions will be easy to answer based on a mature program or a recent experience following a vulnerability assessment/remediation cycle. If you don’t already have precise answers to these, taking the time to answer them will provide clarity into your processes and identify gaps that need to be addressed as your program matures.

Your responses to each of the following will help evaluate your preparedness. They’ll highlight your pain points—room for improvement—and how a preventive approach can help your organization overall. The more specific you are in the metrics you use (e.g., the number of hours, days, staff, dollars, etc.), the more actionable your answers will be for your business goals. 

1. How long does it take your engineering team to determine if you’re using a particular open source component? Speed is critical when a vulnerability is discovered, but answers here may vary significantly, depending on whether your processes are predominantly automated or manual. For example, once you’ve cataloged a component, the number (amount of time) should be drastically reduced in perpetuity. However, if you have not proactively cataloged your use, a fire drill is likely to occur to identify all potential exposures.
2. How long do you believe it should take? Ideally, your team won’t be in the dark about your exposure when the next significant vulnerability is revealed. If your answer to #1 has been inefficient, pulls resources away from other priorities, or is leaving your business exposed to an unacceptable level of open source risk, determine a time-bound goal for this metric. Do you need to drastically reduce your current answer by a few weeks or days, or perhaps just shave off a few hours? The magnitude of the desired  decrease you’re aiming for will help define the steps for you to take.
3. What mechanisms(s) do you use to determine where open source components are used in your software products? These may include spreadsheets, SCA scanning tools, inspecting external SBOMs you receive from your software suppliers or other manual processes. Include all staff involved and all resources used. 
4. How well does your manual process work? Include the number of people or departments involved. Determine the bottlenecks to identify areas for greater efficiency. 
5. What can you automate to maximize efficiencies for your teams? When programmers are pulled off of high-value work in order to reactively manually assess an impact of a new security issue, there is a very real and potentially negative impact on product development schedules. Consider how automated SCA efforts might yield efficiencies that allow you to refocus existing staff’s time on various priorities.
6. Who would benefit by improving the process of identifying open source components? Take a holistic look across your organization. Everyone is vested in ensuring that your product/organization doesn’t make front-page headlines as the source of the next open source disaster or explaining to the US Senate how long it may take to eliminate the vulnerability. The list may include software developers, the legal team, your chief information security officer (CISO), chief revenue officer (CRO), your open source program office (OSPO), and any other stakeholders who are counting on the distribution of products that secure your organization’s revenue, risk exposure, and reputation.  

Build Resilience for the Next Vulnerability

Just as listening to and taking care of your body is essential for overall health, the same applies to your open source program. Efficacy can grow with experience and with a comprehensive approach to software composition analysis. Most importantly, whatever process you put in place needs to become continuous over time. The frequency of the cycle is less important than continuing to work on the process and increasing the frequency over time.

One of the great upsides of an efficient, resilient program: it can free up resources, particularly staff time, so that they can be used where they are bringing the most value. This approach allows your organization to focus on innovative product development work and further company goals and objectives. Staff can concentrate on writing code rather than tracking open source, remediating issues, or managing pain and discomfort. 

How are you upgrading your open source strategies to tackle security vulnerabilities better? Share with us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window .

Image Source: Shutterstock

MORE ON OPEN SOURCE: 

• Blind Trust in Open-Source Software Puts Businesses at Risk
• 5 Steps for Proactively Managing Open Source Software
• Open Source Software: To Get More Value, Manage Your Risks
• The Pitfalls of Blind Trust: Open Source and the Log4Shell Vulnerability