by Dean Vaughan, Vice President of Asia Pacific, Azul
When the engine warning lights come on in a car, one typical reaction for many drivers is to be startled, then continue to drive off, if the car still works. Some may go buy a coupon or voucher later to change the engine oil. Others might schedule a check-up at the workshop.
Yet, many more will procrastinate and wait until a real issue – say, if the engine stalls or if the car stops moving – to get a fix. By then, the problem might have become more serious than when the first warning light went off. This could mean hefty repair costs if the damage has become extensive.
The same applies to cybersecurity. With such complex IT systems and often numerous cybersecurity tools in place today, the first reaction for many IT teams looking at a warning light or alert on a dashboard is to shut it down or wish it away, especially if they are busy.
Just like with a car, if the “warning light” for a cybersecurity issue is generic and does not specifically show what the problem is, human operators often respond with apathy. After all, if you do not know what to fix, how do you fix it? That is one of the biggest challenges today, as cybersecurity teams are overloaded with notifications and dashboards and suffer from alert fatigue.
Worryingly, software supply chain vulnerabilities, which expose organisations to attacks through third-party code, are becoming more prevalent and harder to overcome. By 2025, 45 per cent of organisations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021, according to research firm Gartner.
For example, organisations continue to grapple with Log4Shell, a critical vulnerability found in a widely used Java-based logging component (Log4j). This vulnerability impacted countless servers and applications that used Java software. It exposed so many organisations to cyberattacks simply because Java is used widely in today’s modern IT infrastructure.
The Log4Shell loophole enabled threat actors to run code on a victim’s system and take control. In another incident last year, a major flaw in the Atlassian Confluence collaboration software, a Java application, also enabled hackers to take over a server remotely and steal data.
The challenge is finding a way to zoom in on the specific piece of Java software or code that is vulnerable, instead of manually sieving through the entire stack to find a problem.
This is where Azul Vulnerability Detection, a new SaaS product that continuously detects known security vulnerabilities that exist in Java applications, comes in. By eliminating false positives and with no performance impact, it is ideal for in-production use and addresses the rapidly increasing enterprise risk around software supply chain attacks.
Azul Vulnerability Detection uniquely identifies code run using sophisticated, highly granular techniques inside Azul JVMs and maps against a curated Java-specific database of common vulnerabilities and exposures (CVEs). This produces more accurate results, even for custom code and shaded components.
Doing so means greater visibility for teams to proactively resolve an emerging problem. By focusing the detection on the production environment where the Java code is deployed, Azul Vulnerability Detection shows users what is running in real time, and where exactly the vulnerabilities are.
What’s different from previous tools here is the Java virtual machine (JVM), which provides highly accurate runtime-level visibility into what code is actually running and whether it is vulnerable. This enables faster remediation of vulnerabilities with significantly less operational overhead. Additionally, because the tool is agentless it avoids the performance penalty commonly associated with other security tools that require teams to install and maintain a separate piece of software. Taken together, Azul Vulnerability Detection makes security a by-product of simply running Java software.
Azul Vulnerability Detection enables ongoing detection at the point of use in production, the critical end step of the software supply chain. It applies intelligence while overlaying knowledge of what components are vulnerable, enabling a deep inspection of what constitutes a threat.
Even with shading, which can be used to change the name of a component, say, from Log4j to app.jar, the Azul service will find the component. This is something that a simple file-based scan might fail to catch. Key here is Azul’s deep Java roots, which go back more than 20 years. It understands Java conventions like shading, and it properly recognises what those components are.
Any organisation running Java should be asking where their Java applications are vulnerable and where the efforts to fix these vulnerabilities should be directed towards.
The exploits are out there, and threat actors are using them but for the good guys, a patch is often scheduled for “later”, much like a driver postponing a check after seeing an engine light warning. Well, later has to become now, starting with visibility into one’s system and taking action early.
