Azul has announced an update to its Vulnerability Detection solution that promises to reduce false positives in Java vulnerability detection by up to 99% by only flagging vulnerabilities in code paths that are actually used.
According to Azul, typical scanners scan JAR files for components by name, rather than what the JVM actually loads.
Erik Costlow, senior director of product management at Azul, explained because of the way Java applications work, each component contains many classes, and even though a component may be in the Common Vulnerabilities and Exposures (CVE) database, an application might not be loading the part of the component that is vulnerable.
“Log4j, for example, has over 10,000 classes, and there’s only like five or six of them that are actually vulnerable. So, what we find is that many people use the vulnerable things, but they use it in a safe way,” he said.
As another example, CVE-2024-1597 describes a critical (9.8 out of 10 score) vulnerability in pgjdbc, which is a PostgreSQL JDBC driver. The vulnerability allows SQL injection if PreferQueryMode=SIMPLE is used. However, the entry in the CVE database says “Note this is not the default. In the default mode there is no vulnerability.”
A developer can be using this component and unless they go out of their way and use PreferQueryMode=SIMPLE, they’re safe, Costlow explained.
“What happens is many people look at this score, and they say it’s a 10 out of 10, drop everything, dedicate my engineers to deal with this security vulnerability,” said Costlow. “But the truth is, the majority of them are using it in the default mode, in which case there’s no vulnerability. So, if I’ve taken my people off all the important work that they’re doing, and I’ve said, ‘go fix this vulnerability, patch it right now’ because it’s a critical 10 out of 10, I’ve just wasted a huge amount of time.”
According to Costlow, this type of scenario where a developer would be using a vulnerability component, but not actually activating the part of it that is vulnerable is fairly common.
The latest update to Azul Vulnerability Detection uses a curated knowledge base that maps CVEs to classes that are used at runtime. The company built this by looking at the CVE database and asking how many of the components actually related to Java. Next, it went through those components and figured out what parts of them are problematic and why.
This curated database enables Azul to flag if one of the vulnerable classes in the CVE database is actually being used by the components in a Java application, or if the application is using other classes of a vulnerable component that aren’t considered to be vulnerable pieces.
“What Azul does with vulnerability detection that’s different from many of the other scanners is we continually watch that application to say, ‘did you actually use the thing?’ It’s one thing to have the vulnerable component. People have vulnerable components. There are many things that pose a risk to you, but the question is, do you actually use it in a way that poses a risk to you? What we found, is that pretty often that answer is no,” Costlow said.
The post Azul significantly cuts down on false positives in Java vulnerability detection with latest update to Azul Intelligence Cloud appeared first on SD Times.
Source: Read MoreÂ
