Last December, Veracode reported that more than a third of Java applications still use vulnerable versions of the Log4j Java logging library. This after many engineering teams dropped their regular work and spent their time remediating the remotely exploitable Log4Shell vulnerability that infected many instances of Log4j.

After more than two years of finding and updating the ubiquitous library, you have to ask, why is this still happening? We dove into data from the State of Java Survey and Report 2023, a study of more than 2,000 workers with responsibility for Java, to try to get some answers.

We looked more closely at how some companies approach third-party sources of CVEs and how their approaches might be affecting organizations’ vulnerability to Log4Shell. The two questions we looked at were:

• What source of common vulnerabilities and exposures (CVEs) is most concerning to your company?
• Who is primarily responsible for creating software bills of materials (SBOM) for your in-house applications?

Let’s take a look at them sequentially.

Most concerning sources of CVEs

Survey participants could select more than one response, and the responses available were:

• Open-source libraries and applications
• Third-party libraries and applications (containers, development houses, etc.)
• Code written by our application developers
• Infrastructure software (Kafka, Cassandra, etc.)
• JVMs
• CI/CD tools
• I don’t know
• We are not concerned about CVEs

We were concerned with whether focusing on open-source and third-party libraries and applications was an indicator of vigilance. Here’s what we found out.

Only people who have responsibility for Java were included in the survey, so over 8% of those in Group B is fairly alarming.

Half of respondents in Group A burned hours on Log4Shell, while barely more than a third of Group B did. Group B might have saved time for more strategic work, but the lower figure indicates that they didn’t find and update infected Log4j libraries for clean versions. What could the impact of that be?

Overall, 28.3% of companies in Group A experienced a hacking attempt through Log4j, while 33.9% of companies in Group B experienced an attempted exploit. That’s a 20% increase!

All the data

Identifying SBOM Managers

Survey participants could select more than one response, and the responses available were:

• Application developers
• DevOps
• Platform Engineering
• Security
• Line of Business (product team, marketing, compliance, etc.)
• Operations
• No one is responsible for SBOMs

Application developers were the most common answers, which is an encouraging sign based on how participants answered how Log4Shell affected their organization.

Ironically, security teams with SBOM responsibility had the highest attack rates and the highest successfully. Nearly half (45.6%) of teams that trust their SBOMs to Security were attacked, and one-fifth were hacked successfully. We wouldn’t take those odds!

Meanwhile, 33.8% of Application Development teams in charge of SBOMs were attacked, and 15.7% were hacked successfully.

What this means for DevOps teams

Security is only one part of a larger need to codebases clean and updated. Many DevOps teams struggle to innovate due to legacy code that hasn’t been retired, making maintenance more difficult and increasing exposure to vulnerabilities. Businesses are under pressure to accelerate application innovation cycles and optimize their development resources, while simultaneously ensuring the security of their applications and customer data.

Deployments across platforms and Java versions make code maintenance increasingly complex. Code maintenance becomes the job no one wants and few do, and the problem doesn’t get solved. Is the situation getting better? Find out when we release the State of Java Survey and Report 2024, coming this fall.

Solve problems with Azul Vulnerability Detection

Azul Intelligence Cloud consists of two services which address these challenges for Java applications running in production:  

• Azul Code Inventory helps identify unused and dead code by precisely detailing what custom and third-party code is running (and not just present). Using Code Inventory, DevOps teams slash the time and burden of maintaining and testing unused code, significantly improving developer time and ultimately saving money.
• Azul Vulnerability Detection eliminates false positives by accurately identifying and prioritizing known security vulnerabilities. By detecting vulnerabilities at point of use in production, Vulnerability Detection fills a critical gap at the endpoint of the software supply chain and augments legacy tools for more accurate results, including third-party sources of CVEs.

The post Companies Didn’t Prioritize Third-Party Sources of CVEs, Here’s What Happened appeared first on Azul | Better Java Performance, Superior Java Support.

*** This is a Security Bloggers Network syndicated blog from Security Blog Posts - Azul authored by Azul. Read the original post at: https://www.azul.com/blog/companies-didnt-prioritize-third-party-sources-of-cves-heres-what-happened/