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.
| Segment | I didn’t know about the Log4j vulnerability |
|---|---|
| Named open-source or third-party | 2.3% |
| Did not name open-source or third-party | 8.4% |
Only people who have responsibility for Java were included in the survey, so over 8% of those in Group B is fairly alarming.
| Segment | That vulnerability was not exploited but engineering spent hours remediating the risk (searching for Log4Shell, replacing, etc.) |
|---|---|
| Named open-source or third-party | 50.6% |
| Did not name open-source or third-party | 36.4% |
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?
| Segment | Hackers attempted to use that vulnerability against our company unsuccessfully | Hackers utilized that vulnerability against our company successfully |
|---|---|---|
| Named open-source or third-party | 15.4% | 12.9% |
| Did not name open-source or third-party | 20.1% | 13.8% |
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
| Segment | Log4j had no impact on our company | That vulnerability was not exploited but engineering spend hours remediating | Hackers attempted to use that vulnerability against our company unsuccessfully | Hackers utilized that vulnerability against our company successfully |
|---|---|---|---|---|
| Named open-source or third-party | 16.2% | 50.6% | 15.4% | 12.9 |
| Did not name open-source or third-party | 16.4% | 36.4% | 20.1% | 13.8 |
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.
| Role | Log4j had no impact on our company | That vulnerability was not exploited but engineering spent hours remediating the risk | Hackers attempted to use that vulnerability against our company unsuccessfully | Hackers utilized that vulnerability against our company successfully |
|---|---|---|---|---|
| Application Development | 12.4% | 49.4% | 18.1% | 15.7% |
| Platform Engineering | 12.4% | 49.8% | 20.3% | 16.0% |
| Security | 8.1% | 44.4% | 25.1% | 20.5% |
| Operations | 8.1% | 46.3% | 24.4% | 19.4% |
| DevOps | 11.2% | 48.6% | 19.4% | 16.6% |
| Line of Business | 8.8% | 48.3% | 21.2% | 19.2% |
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.
Code Inventory
Clean code is safe code.
