Warning: Log4j Still Lurks Where Dependency Analysis Can’t Find It

Research shows Log4J still lurks where dependency analysis can’t find it

The best programming practice to include a third-party library in source code is to use the import command. It is the easiest way to do it, and it is also the way that most dependency analysis programs work to determine if a vulnerable library is in play.

Any time code is included without calling it as an external package, traditional dependency analysis might not be enough to find it — including when Java coders use a common trick to resolve conflicting dependencies during the design process.

Log4J Warning

A new study by jFrog found that 400 packages on repository Maven Central used Log4j code without calling it an external package. Around a third of that came from fat jars — jar files that include all external dependencies to make a more efficient product. The remainder came from directly inserting Log4j code into the source code, including shading, a work-around used when two or more dependencies call different versions of the same library in a way that might conflict.

While 400 may not seem like a lot for Maven Central, where Google found 17,000 packages implementing the vulnerable Log4j library, some of the 400 packages unearthed by JFrog are widely used.

“Some of the packages, we were familiar with. Some are commercially backed, some are maintained by the community. Some were pretty significant,” said Asaf Karas, chief technology officer of JFrog Security Research.

JFrog scanned Maven Central using an in-depth open-source scanner it released on December 28. Karas suggests enterprises apply to their own java applications. Maven Central’s packages may be indicative of how corporations coded their own internal and product software.

While the 400 packages contain unlisted Log4j, around 70% of the time, they did contain dependencies using Log4j that might light up a scanner (albeit pointing in a different direction).

JFrog has not yet released the names of the potentially vulnerable packages it discovered on Maven Central while it completes disclosure.

“It’s a process where we’re trying to really understand which are the ones that are the most popular and then disclose that information there first,” said Karas

“But we didn’t want to postpone the fact that people should be aware that this kind of threat exists.”