Are Critical Vulnerabilities Lurking in Your Java Ecosystem?

Java, the popular object-oriented language renowned for its portability, performance, and security, is often the preferred choice for organisations building everything from enterprise and cloud-native applications to Android apps.

However, despite these strengths, Java's popularity and the complex ecosystem of third-party libraries it relies upon have also made it a prime target for malicious actors to exploit vulnerabilities. According to the Datadog "State of DevSecOps"[1] report, a staggering 90% of Java services are susceptible to one or more critical or high-severity vulnerabilities, often stemming from external dependencies, compared to an average of 47% for other technologies. This discrepancy is concerning and points to inherent issues within the Java ecosystem.

What is interesting to note is none of these vulnerabilities is due to the poor coding practices of the internal development teams or inherent flaws in the Java language itself but from libraries beyond the development teams’ control. It's exceedingly rare to find a Java application deployed in production that doesn't include at least one third-party library in its deployment artifact.

For the sake of this article, the vulnerabilities that can come out of insecure coding practices are discounted and the focus is on the third-party libraries as highlighted in the Datadog report. This article explores the factors that contribute to Java's vulnerability, delves into how third-party libraries can become hidden security risks and looks at how to mitigate those risks.

Delving into the complexity

One of the reasons why Java applications score so high on the vulnerability index is due to the reliance on a vast network of interconnected open-source components that are a key part of the java eco system. These can be frameworks (Spring, Hibernate, Struts, Log4J), build tools (Ant, Maven and Gradle), application servers (Tomcat, WildFly, Jetty) and even JDK and JVMs. Each of these libraries has further dependencies, which are indirectly added to the java application and and the result is a huge threat surface.

While these libraries offer valuable functionality and save valuable development time, they also introduce potential points of weakness. Each library, with its own codebase and dependencies, expands the attack surface of the application. As the number of libraries increases, so does the complexity of managing and securing them. A single vulnerability in a seemingly minor dependency can cascade through the entire system, compromising the security of the whole application.

Transitive Dependencies

The issue of complexity is further exacerbated by the concept of transitive dependencies. When a Java project includes a library, it often automatically pulls in other libraries that the original library depends on. These indirect dependencies, known as transitive dependencies, can be numerous and difficult to track. Most developers might not even be aware of all the libraries hiding beneath the surface of their code. This lack of visibility makes it challenging to assess the security posture of each component and apply timely patches.

A vulnerability hidden deep within a transitive dependency can remain undetected for extended periods, leaving the application exposed to potential attacks. This risk is particularly concerning given that the speed at which vulnerabilities are being exploited is increasing rapidly, with 56% of vulnerabilities exploited within seven days of disclosure [3]. According to the "2023 Global State of DevSecOps" report by Synopsys [6], a survey involving 1,000 IT security professionals revealed that 28% of respondents indicated it could take their organisations up to three weeks to address critical security vulnerabilities in deployed applications, with another 20% noting that the process could extend to a month.

A prime example is the 2021 Log4J vulnerability [10], which exposed a critical flaw in how the library processed certain types of log messages. This vulnerability allowed attackers to remotely execute code on affected systems, potentially leading to widespread compromise due to Log4J's widespread use in Java applications. Though Log4j was not directly added as a project dependency by developers, it was added as an indirect dependency as part of major open-source libraries like Apache Struts, Solr, and Elasticsearch. This incident underscores the critical importance of understanding and managing not only direct dependencies but also the hidden vulnerabilities lurking within the sprawling network of transitive dependencies that make up the modern Java ecosystem.

While upgrading Log4j itself might appear straightforward, the reality for many organisations is far more nuanced. In projects utilising older versions of dependent components, a simple library upgrade could trigger a cascade of compatibility issues, potentially necessitating updates across the entire interconnected ecosystem. This ripple effect can lead to significant disruptions, requiring extensive testing and validation to ensure the application's stability and functionality. In such cases, what seems like a routine patch can quickly escalate into a complex and time-consuming endeavour. These findings highlight the urgent need for more effective dependency management and quicker vulnerability remediation to protect against evolving threats.

Challenges in Maintenance and Dependency Management

Recent analyses highlight a concerning trend in the maintenance of open-source projects. Reports indicate that nearly 20% of open-source java projects maintained in 2022 are no longer being updated in 2023. This decline in maintenance significantly increases the vulnerability of these projects to security exploitation.

The 2024 Open-Source Security and Risk Analysis Report by Synopsys [5] sheds more light on this issue, revealing that an alarming 91% of codebases include components that are over ten versions behind the latest release, further amplifying their susceptibility to security threats. In our experience working with high profile clients, we have noticed this first hand. Working with outdated versions not only negatively impacts your security posture but also adds technical debt, hinders innovation, and may prevent developers from utilising new features introduced in the latest versions.

This situation, therefore, impacts security and impedes modernisation efforts.

Cognitive Overload on Developers

But why can’t development teams just bump the version to the latest and solve the problem? Often, the reason lies in the complexity of dependencies. In a Java eco system, upgrading a library is not always straightforward due to potential compatibility issues with other dependent components, which can lead to extensive retesting and refactoring of existing code. We have noticed that development teams are already stretched thin juggling multiple responsibilities from new feature development to bug fixing and performance optimisation.

Adding the task of constantly monitoring and updating dependencies can lead to burnout and mistakes, further exacerbating the security risks. Convincing the business to support an extensive library upgrade can be an uphill task, as it requires significant time and investment without immediate visible benefits. This highlights the critical need for proactive dependency management and regular security audits to mitigate these risks and maintain a robust security posture. Regular updates and vigilant oversight are essential to prevent the security vulnerabilities that come with outdated dependencies.

Recommendations for Mitigation

To mitigate these risks, it's crucial to adopt best practices for dependency management

• Comprehensive Scanning. Development teams should conduct a Technical "Know What's In Your Code" assessment. Regularly scan your entire dependency tree, including indirect dependencies, for vulnerabilities using tools like OWASP Dependency-Check or Snyk. Use Software Composition Analysis (SCA) tools such as Synopsys Black Duck, WhiteSource, or Sonatype Nexus Lifecycle to identify outdated libraries and security risks. These SCA tools can also generate Software Bill of Materials (SBOMs), providing a detailed inventory of all components and their versions used in your applications, which is crucial for maintaining visibility and managing security throughout the software development lifecycle.
• Stay Updated. Keep all dependencies up-to-date and apply patches promptly. Use tools like GitHub’s Dependabot or Renovate to regularly update dependencies barring the major version upgrades. For major version upgrades use tools like OpenRewrite which is a powerful automated refactoring tool for source code particularly for tasks like framework migrations, vulnerability patching, and major version upgrades.
• Assess Dependency Health. Evaluate the health and maintenance frequency of third-party libraries before including them in your projects. Tools like OpenSSF Scorecard can help assess the security posture of open-source projects.
• Minimise Dependencies. Use only necessary libraries to reduce the attack surface. Consider using lightweight or distroless container images to limit potential vulnerabilities.
• Security Training. Provide regular training for development teams on secure coding practices and the importance of dependency management. Encourage a culture of security awareness and proactive vulnerability management.

Conclusion

The growing complexity of Java applications, primarily due to the extensive use of third-party libraries and transitive dependencies, poses significant security challenges.

The Datadog "State of DevSecOps" report and the Synopsys “2023 Global State of DevSecOps” report highlight how these dependencies can become major vulnerabilities if not managed properly. The alarming statistic that 90% of Java services are susceptible to critical vulnerabilities underscores the need for proactive and robust dependency management practices.

By incorporating comprehensive scanning, leveraging Software Composition Analysis (SCA) tools, and maintaining an updated and healthy dependency ecosystem, organisations can significantly reduce their security risks.

Additionally, fostering a culture of security awareness and providing regular training on secure coding practices are crucial steps towards a more secure software development lifecycle. Addressing these issues head-on will not only protect applications from potential exploits but also reduce technical debt, allowing for continued innovation and modernisation in the Java ecosystem.

Are you struggling to secure your Java applications?

At ShiftLeft, we specialise in integrating security engineering into every phase of the development lifecycle, ensuring your applications are not only functional but also fortified against threats.

 Our DevSecOps Approach Includes

• Continuous Monitoring: Real-time visibility into your application’s security posture.
• Automated Scanning: Comprehensive scans that cover both direct and indirect dependencies.
• Prioritisation: Focus on the vulnerabilities that matter most, reducing noise and enhancing efficiency.
• Expert Guidance: Tailored strategies to mitigate risks specific to your environment.

Don't let your Java services be the weak link in your security chain. Partner with us to build resilient applications that stand up to modern threats.

Contact us today to learn how we can help you secure your Java applications and protect your business from potential exploits.

References

• https://www.zdnet.com/article/only-5-5-of-all-vulnerabilities-are-ever-exploited-in-the-wild/
• https://www.datadoghq.com/state-of-devsecops/
• https://www.securityweek.com/vulnerabilities-being-exploited-faster-than-ever-analysis/
• https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
• https://www.synopsys.com/blogs/software-security/synopsys-devsecops-report.html
• https://docs.openrewrite.org/
• https://docs.renovatebot.com/
• https://www.synopsys.com/software-integrity/software-composition-analysis-tools/black-duck-sca.html
• https://www.sonatype.com/products/open-source-security-dependency-management
• https://www.trendmicro.com/en_us/what-is/apache-log4j-vulnerability.html