Software vendors must understand the implications a breach in open source software might have on their own product or service. In December 2021, for example, a vulnerability was discovered in Log4j, an open source logging library extensively used by apps and services across the internet.
Not addressing this vulnerability would have given carte blanche to cybercriminals to hack into systems, steal passwords and logins, steal data and inject malicious software into networks. Log4j is used by millions of computers that run online services and this vulnerability caused problems for organizations, governments and individuals alike.
This particular vulnerability appeared to require very little expertise to exploit, which caused some to rank it as one of the most severe in years.
Not surprisingly, the U.S. government recently hosted a meeting with the likes of Oracle, Apple, Facebook, Google, IBM and Microsoft, among others, with a view to improving cybersecurity in open source software. And it wasn’t just big tech that attended the White House meeting—the U.S. departments of Defense, Commerce, Energy and Homeland Security were also there to lend their input.
The main focus of the meeting was to discuss ways to make open source software more secure by design—and also to make sure that any breaches were identified more expeditiously and dealt with robustly upon detection. Improving the response times for distributing and implementing fixes is vital if organizations are to ensure that business software is adequately protected when it is integrated with or working with compromised open source software.
Are Vendors Slacking?
The discovery of any vulnerability in commonly installed open source software should drive vendors to analyze and create solutions for each of their products—the more products in a vendor’s portfolio, the longer this process should take.
It stands to reason, therefore, that many IT security teams choose the broad-based approach to security that is available from third-party software support because these solutions are not software- or vendor-specific. More importantly, these fixes are usually ready before any vendor patches can be developed.
As an example, Oracle was slow to address the fallout created by the Log4j bug—a comprehensive fix was not quickly provided by them. The bug was publicly disclosed by the Apache Foundation on Friday, December 10, 2021. There were global alerts about the bug’s severity issued by governments all around the globe.
The 24- to 48-hour period following the disclosure of any vulnerability is critical— this is when security teams need to race to find a solution. It would appear that Oracle was late to the party with respect to delivering a full solution.
The usual media hype persisted regarding the possible effects on organizations and products. Using the broad-based approach to security favored by third-party software support, many organizations were able to quickly determine which products were not affected or were able to refrain from using any impacted frameworks.
Customers Expect Answers and Solutions
The Log4j bug caused problems with a Java class file used for logging system issues. Many organizations provided clients with the necessary steps to remove the vulnerable Java class so that it was not being used on their systems. Oracle, on the other hand, could only issue a general advisory followed by a series of patches, leaving customers in the lurch for another week after the Apache Foundation’s initial revelation.
In cases like these, especially involving such a potentially damaging bug, the big vendors need to provide clarity for their customers, who will naturally be worried. You need to be agile enough to be aware of the problem in the first place, undergo research and publish a response/solution swiftly—this is what customers want. They don’t want or expect to have to go through a perplexing patching process for a suite of various products. Your customer response team needs to be ready and waiting with answers and potential solutions.
Meanwhile, discussions between the public and private sectors continue at the very highest levels with regards to any potential open source threats. The White House has clearly taken this very seriously, so it is crucial that all software vendors do the same and are able to respond quickly if any of their software is impacted by a Log4j-style bug. A good first step would be to integrate vendors fully into these ongoing discussions.
