Developing a Plan to Respond to Critical CVEs in Open Source Software

COMMENTARY

In 2020, the SolarWinds incident served as a wake-up call for the tech industry, highlighting the urgent need for organizations to refine their response strategies to critical CVEs (common vulnerabilities and exposures) and security incidents. It prompted many companies to scrutinize their operational frameworks, particularly the transparency and security of their open source supply chain. Organizations recognized the critical need to bridge gaps in their processes and to empower developers with the knowledge of secure development practices, and began figuring out how to guide developers to using secure open source components.

Following the SolarWinds supply chain attack, 2021 saw the Log4j incident that involved a vulnerability in the Log4j logging library, a widely used Java-based logging utility. The most recent incident that shook the industry was the XZ Utils backdoor that could have become yet another wide-scale open source supply chain attack. A mix of technical and social engineering sophistication was all too close to infecting the world.

The financial impact from exploited vulnerabilities can be devastating to organizations. In July 2021, a ransomware attack targeted Kaseya's VSA, a popular IT management software used by managed service providers (MSPs) to manage and monitor computers and networks. The attackers exploited a vulnerability in Kaseya's software to deploy the REvil ransomware across Kaseya's customer base, affecting MSPs and their clients. The attackers demanded a $70 million ransom.

Small Businesses Also Face Danger

Not only are large organizations vulnerable to CVEs (a unique identifier that describes one individual vulnerability) being exploited, but small businesses often are in the crosshairs themselves. A cybercrime study from Accenture revealed that more than 40% of cyberattacks happen against small businesses. However, only 14% of small businesses are prepared to defend themselves. 

Open source projects are incredibly useful for developers because they offer ready-made solutions that can easily be integrated into new software, saving time and resources. However, there's a downside to this convenience. Sometimes, these open source components are outdated, no longer maintained, or lack a strong focus on security. Organizations are also further hampered by not having a strategy to respond to new vulnerabilities, along with how it is used within the application. However, the majority of upstream does do a decent job of releasing fixes and updates in a timely manner. The issue is that even though fixed versions are available, consumers downstream still continue to download and use known vulnerable versions.

When developers integrate certain projects into their software, they may unintentionally introduce vulnerabilities exploitable by cybercriminals, often through transitive dependencies. Although the primary software intended for use might be secure, underlying libraries and components, which remain unknown to the deployer, can introduce risks. This scenario leaves organizations susceptible to attacks, as they may not be aware of the vulnerable components their software depends on, nor have a rapid and effective response plan for potential exploits.

Building Comprehensive Asset Inventories

To effectively respond to CVEs in open source software, organizations should prioritize building a comprehensive asset inventory. Additionally, generating software bills of materials (SBOMs) for applications is imperative, as they provide a standardized format for consuming software component inventory information, and SBOMs are not a silver bullet to address the whole problem. The actual execution of formats and contents for SBOMs vary widely as well. Open source components can often also be found in commercial third-party software. In fact, the "2024 Open Source Security and Risk Analysis Report" from Synopsys revealed that nearly all (96%) of the codebases analyzed contained open source components.

Organizations working with third-party vendors should require them to provide SBOMs for their software products as part of contract negotiations. This will help organizations keep informed of any vulnerabilities in their third-party software and keep vendors accountable for remediating vulnerabilities. Knowing where your critical assets and the open source components that are a part of them are allows for an efficient triage process when it's time to respond to a critical CVE.

Leveraging software composition analysis (SCA) tools can help construct SBOMs efficiently and detect known CVEs associated with these components. According to the Open Worldwide Application Security Project (OWASP), component analysis is the process of identifying potential areas of risk from the use of third-party and open source software and hardware components. 

These tools enhance efficiency by automatically creating comprehensive inventories of software components and their interdependencies. They perform scans that identify outdated components and detect any associated known CVEs. However, due to the lack of universally accepted standards for naming and versioning these components, scanner vendors often face challenges in accurately identifying software, resulting in a high rate of false positives. 

This issue places a significant operational burden on enterprises to verify results. Furthermore, to manage costs and overhead, these scanning tools typically depend on the National Institute of Standards and Technology's National Vulnerability Database (NVD), which itself struggles with data quality and the timeliness of updates.

Additionally, scanners frequently experience delays of days, weeks, or even months in providing accurate CVE data. It is crucial for organizations to set these scans to run routinely and automatically on all applications that incorporate open source software components. Some tools offer the capability to observe applications at runtime and detect which libraries are actually in use by the application, to help security teams and developers prioritize the backlog of security findings that need to be remediated. OWASP has curated a list of free, open source, and commercially licensed tools.

Support Is Needed

Remediation of vulnerabilities is not possible without support from development teams that own and support the applications. Instituting developer trainings that are focused on security topics and having security champions that can serve as focal points for promoting security awareness and best practices is essential. Establishing a clear process for developers to respond to critical CVEs is essential for having a rapid and coordinated response in the face of another incident like the Log4j CVEs. 

Moreover, it is important to have a process to analyze impact before deeming a vulnerability as "Critical" for an organization. Define escalation paths for critical CVEs that specifically define when a reported vulnerability escalates to an incident, ensuring all the correct incident management processes are followed to minimize the operational impact on the organization.