This week marks three years since the Log4Shell vulnerability was disclosed, described as one of “the most severe vulnerability ever” and “the biggest supply chain threat since the Solarwinds attack.”

Speaking this week with Tal Zarfati, lead architect at JFrog, says the significance of Log4Shell was so significant as it “affected virtually anybody”, because anybody who worked on Java probably used the Log4J Library. 

Much Greater

As we looked back at the Heartbleed bug earlier this year, Zarfati says the impact of Log4Shell was so much greater as it is a “clear spot in your threat modelling.”

This is because nobody looked for Log4Shell or Log4J, and he says you never would have imagined that a logging library would introduce that kind of a huge risk to anybody.

“Once this came out every major software development, every company that does some development wanted to know where that vulnerable Log4J version is in my organisation,” he says. In particular, every business and security team wanted to be sure that no new version of a build pipeline gets released, especially with that problematic version.

“If it's a task dependency - that is, it's a dependency of your dependency - if it's already been used in a binary that you are distributing, how can you track which binaries have been downloaded?” he asks. “How can you block binaries that are affected of versions of your application that are affected by Log4J to be consumed by your clients.”

Exploitable

One of the considerations is if there are vulnerable versions of Log4J, how can you know if there a vulnerability in my version that is actually exploitable? “Log4J is a logging library and if I don't get any input from an attacker, the Log4J vulnerability is useless because in order for it to be exploited, an attacker needs to be able to manipulate the input.”

Three years on thought, Zarfati says people are still talking about this vulnerability, especially when it comes to talking about supply chain security, describing it as “that scarring.”

Asked if he sees more more interest in that sort of supply chain bug after the incident, he says it did bring to the surface the value of scanning binaries, scanning artifacts, scanning them for third-party dependencies and managing and orchestrating those in a single place in your organisation, in order for you to have the control about what goes in and goes out.

Or did it bring a lot of attention to more generally to that sort of vulnerability, and knowing what is running on your applications? “Absolutely, Log4Shell brought a lot of attention to the entire concept of managing your vulnerabilities, and managing your supply chain,” he says.. 

“It was a little bit different, mostly because Heartbleed, in that sense, was a software that was being used for your OpenSSL to do your certificate signing. If you ran the OpenSSL server and then you were at risk.

“With Log4Shell, the concept of translating the dependencies, that is you might not even know that you explicitly are using Log4Shell, you're using a package that in turn used a package, that in turn used a package, that in turn used a package that in turn used Log4J. Now that package is all the way down your dependency chain and has introduced that huge risk to you.”

Blast Radius

Zarfati says he believes the biggest effect from Log4J is that the blast radius was much bigger and the number of action items that you had in order to mitigate that was much larger.

“In Heartbleed, the action item was pretty simple: upgrade the version of your OpenSSL running on your server,” he says. “The Log4Shell vulnerability had you running all across your deck stack and upgrading, rebuilding, recreating almost every piece of code that you had in your organisation if you are a Java based company.

“In my opinion it strengthened the need to catch those kind of issues as further left as possible. That is the cost of responding to the threat.”

Legacy Software

Now we are three years on, do people still come to JFrog and say ‘we've got this problem’, and is Log4Shell still a vector now? 

He admits he doesn’t know complete statistics, but the fact is that people use legacy software all the time and the way that software supply chain works is that companies that do not keep a close track on what they are running, and do not enforce policies based on security in their supply chain organisation.

“The problem is that three years ago, everybody talks about Log4Shell, but nobody tried to change their organisation to make sure the vulnerable version is not going to the organisation,” he says.

Zarfati says the incident enabled JFrog to continue its mission to “be the owner of all the Ops related operations in your organisation” in what he describes as “every ops, that is DevOps DevSecOps and MLops.”

“We scan vulnerabilities in the context of how the user uses third-party software in order for them to fix what matters the most first, and reduce the load of fixed vulnerabilities,” he says.”One of the challenges in managing all the mass of supply chain and vulnerability scans is the fact there are too many vulnerabilities, too many alerts and the first thing that user wants to do is to prioritise those.

“We check for the secrets in the code. We know how to find different problems and configurations and other types of exposures once you scan those.”

Looking forward, Zarfati says the industry is getting more mature in its ability to handle these challenges, but part of that is going to new vectors such as machine learning “because that industry is still less mature than classic software development.”

He says that not everybody who works in the world of MLops has adopted supply chain management standards for machine learning supply chain management.

Dan Raywood Senior Editor SC Media UK

Dan Raywood is a B2B journalist with more than 20 years of experience, including covering cybersecurity for the past 16 years. He has extensively covered topics from Advanced Persistent Threats and nation-state hackers to major data breaches and regulatory changes.

He has spoken at events including 44CON, Infosecurity Europe, RANT Conference, BSides Scotland, Steelcon and ESET Security Days.

Outside work, Dan enjoys supporting Tottenham Hotspur, managing mischievous cats, and sampling craft beers.