WhiteSource this week made good on a promise to add Log4j vulnerability remediation capabilities to both its free and commercial tools for updating open source software components.
Susan St. Clair, director of product management for WhiteSource, said the Log4j remediation preset capability can find and automatically fix both direct and indirect Log4j dependencies.
In addition, WhiteSource has created an online resource center to provide access to Log4j remediation and secure coding best practices.
There are now three vulnerabilities identified in various versions of the ubiquitous open source Log4j software, routinely used to manage logs created by Java applications. WhiteSource research estimated that more than half of the applications (52%) used by the top 2,000 organizations in the software development industry employ Log4j to manage logs.
The Log4j vulnerabilities allow cybercriminals to take advantage of a Java naming and directory interface (JNDI) to force a Java application to connect to an LDAP server and remotely execute malicious code, otherwise known as an RCE attack. The latest versions of Log4j resolved all known vulnerabilities.
The Log4j vulnerabilities are only the latest in a series of zero-day vulnerabilities that wreaked havoc on security and IT operations teams. In December, the rush began to first determine where all the instances of a vulnerable application were running and then attempt to marshal the application development expertise required to apply the patches that remediate those vulnerabilities.
On the plus side, however, the increasing number of zero-day vulnerabilities is pushing more organizations to adopt a set of DevSecOps best practices that can help organizations define a process for prioritizing and remediating vulnerabilities in a way that reduces the overall level of stress for all concerned, noted St. Clair.
At the same time, St. Clair said many organizations are also reviewing their dependency on open source software in the wake of a series of high-profile software supply chain breaches. While open source software—especially projects with many contributors and regular reviews—is generally secure, there are smaller projects (such as Log4j) that depend on the security expertise of a relatively small number of contributors. Each organization will need to determine how comfortable they are relying on specific open source projects within the context of their ability to use tools to automatically update that software any time a new vulnerability is discovered.
Pressure is also starting to increase on organizations that rely on open source software to contribute more to security reviews. White House national security adviser Jake Sullivan recently sent a letter to major software companies and developers inviting them to discuss initiatives to improve open-source software security, starting with a one-day discussion this month to be hosted by Anne Neuberger, the deputy national security advisor for cyber and emerging technology.
One way or another, the security of open source software will steadily improve. The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised $10 million to help maintainers embrace best practices to better protect open source projects. One particularly nasty attack vector is malicious code injected into software by bad actors pretending to be just another contributor to the project. Google has pledged $1 million to help open source developers adhere to National Institute of Standards and Technology (NIST) in response to the recent executive order on cybersecurity issued by the Biden administration. Administered as a pilot program by the Linux Foundation, that effort is part of a larger $10 billion commitment that Google previously made to advance open source security.
In the meantime, security professionals must understand that cybercriminals are becoming more adept at exploiting zero-day vulnerabilities within hours of disclosure. As such, the need to remediate vulnerabilities as quickly as possible has never been greater.
