Dive Brief:

• More than 40% of users continue to download vulnerable versions of Apache Log4j, despite urgent efforts to upgrade the software, according to Sonatype, which owns the Maven Central repository, which is considered the most significant repository of Java packages. 
• "This is because so many companies simply have not covered the basics," Brian Fox, CTO of Sonatype, said via email. Fox says that many companies don't actually know what is in their applications so instead of launching targeted updates they are doing busy work. "In short, they are still trying to build their inventory before they start to react."
• More than 17,000 Java packages, representing about 4% of the ecosystem, have been impacted by the Log4j vulnerabilities, according to an updated blogpost from Google's Open Source Insights Team. The revised figures are based on Log4j-core, after prior figures were calculated based on the original CVE, which included Log4j-core and Log4j-api. 

Dive Insight:

Open Source Insights is an experimental service that Google developed and hosts as a means of helping developers gain a better understanding of the structure and security of open source software packages. 

The recent Log4j vulnerability allows attackers to perform remote code execution by taking advantage of insecure Java Naming and Directory Interface (JNDI) lookups. 

As of Dec. 16, almost 36,000 of the available Java artifacts from Maven Central were dependent on the affected Log4j code. Those figures meant that 8% of all software packages on Maven Central had at least one version impacted by the code. That represented an enormous increase from the 2% average, Google said. 

The figures reflect an industry that is still scrambling to recover from what many see as a historic event in the information security space, as Log4j, which is found in hundreds of millions of devices worldwide, has been attacked by opportunistic threat actors looking to take advantage of a major vulnerability. 

Log4j versions beyond 2.0 is in the top 0.003 percentile of most popular downloads across Maven Central and is the standard logging framework of choice for most other Java Open Source components, according to Fox, as every other framework interoperates with the Log4j API. 

"The implication of this is that Log4j usage may be required transitively by your direct dependencies many levels deep," Fox said. "Modern build tools make it relatively easy to override the version used by its dependencies." 

However, two things must be true, Fox said: 

• The update must be API compatible with a dependencies' usage.
• An organization must know that they are actually using Log4j and in which application they need to apply the override.