When Log4Shell emerged, it shook some of the most powerful institutions on the planet. After the vulnerability was discovered in late 2021, Jen Easterly, director of the US Cybersecurity and Infrastructure Security Agency (CISA), labelled the zero-day as “one of the most serious I’ve seen in my entire career, if not the most serious.” Ars Technica dubbed it “arguably the most severe vulnerability ever,” while the Washington Post described security professionals’ forecast as “border(ing) on the apocalyptic.”

These weren’t unfounded claims. Log4Shell affected the Apache Log4j logging framework, which is widely used to log system events, and could be easily used to perform remote code execution (RCE). The attacker could merely prepare a malicious Java file and include a short string in whatever data would be logged by the application server. When processing the log entry, Log4j would execute the malicious Java code, thus permitting RCE. If that code was a remote shell, the attacker could gain remote access with the privileges of the system user.

Because Log4j is such a popular logging tool and used in so many organisations, the vulnerability potentially affected hundreds of millions of systems. Further complicating the situation, the vulnerability was discovered after it had been present within the framework since 2013. So by the time it was discovered, it had been exploitable – and invisible to defenders – for nearly a decade.

Log4Shell embodies the cybersecurity nightmare of a long-buried and widely-spread zero-day vulnerability. Such flaws lie hidden in popular software and applications for years, and when they emerge, they send affected organisations and regulatory agencies scrambling to fix years of vulnerability as quickly as possible.

The silver lining

Events like these often serve as a necessary wake-up call to many organisations. Invicti Security’s Spring AppSec Indicator surveyed 1700 customers and found a large spike in vulnerability scanning correlating with the announcement of Log4Shell, spanning the last quarter of 2021 and first quarter of 2022.

For those organisations, Log4Shell was instructional. Even if they did not find that specific vulnerability in their environment, the prompt to start scanning with greater intensity meant they would have uncovered more vulnerabilities within their assets than they might otherwise have done.

While in many cases the emergence of Log4Shell served as a rallying cry for those who increased their scanning operations, many will not have learnt that lesson. For those organisations, Log4Shell and other vulnerabilities like it will continue to cause problems.

Why don’t people scan more?

It shouldn’t take a public security crisis for organisations to intensify their security scanning activities, but there are practical reasons why some don’t take that route. In fact, there are several technical and organisational obstacles that can prevent suitably frequent vulnerability scanning.

Businesses are often inured to the fact that bugs, including security issues, will always exist somewhere in their environment. While that’s a reality, it can make organisations complacent about their vulnerabilities overall. Often, such organisations will not devote their already limited programming resources to a problem they believe to be a fact of life. This might be seen as a calculated risk, but organisations often don’t realise how much they’ve miscalculated until it’s too late.

Those organisations that do scan typically do so in a haphazard way. Many use multiple uncoordinated scanners and scanning methods and then collate, verify, and filter that information manually, making the process menial and time-consuming, and ultimately hampering them from getting a unified view of their vulnerabilities. Accuracy suffers in this approach, too, because users often can’t tell which issues are real vulnerabilities and have even less clue about how to fix a specific vulnerability quickly.

When scanning works

The good news is that vulnerability scanning – when carried out efficiently – really works. The Invicti Spring AppSec Indicator showed that, since 2019, businesses increased their scans from 49 a month to 73 scans a month (on average). Since 2021, the number of severe vulnerabilities that the same group discovered has dropped by 19%.

One of the reasons for that success was the surveyed groups’ use of Invicti’s dynamic application security testing (DAST) solution. Advanced automated DAST gives organisations a way to continuously scan their environment with greater accuracy and efficiency than other forms of security testing. For tools equipped with automatic verification, DAST tests applications more accurately than other approaches because when it finds a potential vulnerability, it safely simulates an attack on that asset. The attacker’s perspective finds vulnerabilities that are actually exploitable to not only sidestep many false positives but also show which issues need to be prioritised.

The Invicti approach to DAST also provides coverage throughout the application portfolio with the ability to scan everything from single-page applications (SPAs) to multi-level forms to APIs such REST, SOAP, and GraphQL. Built-in security checks can uncover application vulnerabilities but also vulnerable components such as Log4j. This can be done regardless of the language in which a website or application was written, the framework used, or even whether the source code is available – if it runs in a modern browser, the scanner can test it.

Additionally, DAST can be built directly into the software development lifecycle (SDLC), thus allowing apps to be tested and scanned for vulnerabilities from earlier stages of their lifecycle, whether already deployed or still in development.

Don’t wait for the next zero-day

While Log4Shell appears to have prompted organisations to scan more intensely and frequently, we shouldn’t rely on these public cybersecurity crises to remind us to scan.

Breaches can have a catastrophic effect on an organisation, whether through reputational damage, compliance blowback, or remediation costs. On average, a security incident costs an organisation about $4.35 million. This can prove a real setback for a growing business, hobbling long term strategic efforts and draining resources from potential profit centres.

Continuous vulnerability scanning and security testing embedded within the SDLC will allow organisations to stay on top of their application security and find emerging vulnerabilities – whether they’re new or have lain dormant for years.