Skip to content ↓ | Skip to navigation ↓

I was sitting in a meeting discussing application vulnerability concerns raised by a customer and had a thought… it hurt a little but I got over it.

There are security issues in every app, regardless of language. Java apps, however, seem to get more attention lately, primarily due to the number of security issues in the JREs/JVMs we use, and that those apps come under higher scrutiny from customers because of JVM issues.

Java applications seem to have gone through a phase in which we decided that shipping the app with a JVM reduced test and support matrices for vendors, while in the old days nobody cared much about it. The Java environment had a reputation for being secure by design to some extent at first and we coasted on that for quite a while.

shutterstock_113180041Then, we started getting more and more security updates to our JVMs and we had to start working out how to keep products up-to-date with our own fixes in addition to the JVM updates. Consequently, vendors suddenly became responsible for re-distribution of the JVM fixes.

All of this is relevant to my point because as I sat in this meeting and walked through a list of issues, more than half of the issues found by the tool were defects in the JVM that we shipped and were not ever executed by code paths in our application.

We were lost in the false positives trying to filter our applications issues out of all of this noise. I realized then that any given java application’s image is detrimentally affected by the JVM’s security issues. Customers want the app but don’t want the JVM because it has a bad reputation, regardless of whether the security issues are being exposed by the application or not.

In turn, we as vendors of Java applications are suffering from the platform’s reputation in a way that a C program running on Linux is not tainted by security issues of the Linux distribution.

I think that the future will see more companies avoiding deploying the JVM with their app and making the customer responsible for it. Will that help? I don’t know.

It will help to begin to distance the applications from the OS they run on and that may improve the view of Java apps as acceptable, but we will continue to pay the price of being seen as too close to the JVM/OS we run our Java apps on for some time yet.


Related Articles:


BB-Shirt-TwitterAdv3d1Back by popular demand…

Hey, InfoSec Pros! We’re giving away dozens of these awesome ‘Breaching Bad’ T-shirts to some lucky Twitter followers. Make sure to follow us @TripwireInc and RT to be entered for a chance to win! Contest ends Dec. 18, 2014. Click here for Terms & Conditions.


10 Ways Tripwire Outperforms Other Cybersecurity Solutions
  • Steve

    I can't recommend Java as long as Oracle still pushes crapware with the installer (most notably the Ask toolbar). Also, there's no way to auto update Java.
    If you'd like people to not think of Java applications as tainted crap, put some pressure on Oracle to fix Java's image.

  • John Brownstein

    Organizations have difficulty being responsible for the JVM and APP's. So is the issue a responsibility rather than reputation? No one wants to be responsible. Java's issues related to security are not just about vulnerabilities, it it about the attack surface and responsibility.

    I think some of the other problems with JAVA/JVM is that customers moved on, thus they have far more options in terms of platform, risk management, security controls, etc.
    1. Virtualization killed the need for a JVM. So, customers have other options and can consider resources in different ways.
    2. Oracle and Java developers have not adjusted to the rapid pace of consumer driven APP's and Beta Culture.
    3. There are different security controls which we can now use. While Java implements these in some instances, it can be dated and not holistic.
    4. Organizations think about their attack surfaces far differently then 10 years ago.

    In terms of client side Java APPS they just do not mater anymore. All you have to do is read what Steve wrote, why the hell in 2015 will any user who would want to install a Java APP want the ASK tool bar? This sucks for customers… Most will choose not to install to install.

    I think the next axe to fall is the Java Middleware crises. This will be a bigger blow to Java, and we need to talk about this more. Java is not just about the Browser or APPs, there is lots of Java glue out there.

    Let also not forget that Java is an ecosystem designed for a different time addressing different problems. Basically, if you want to run a VM on my already virtualized environment or want my customers to do a double install (JVM and APP) your going to have to take responsibility for that VM which is not needed for languages. Organizations have other options, it time for Java to die and for us to prepare for the post Java World.

    Thanks for the article, sorry jumping around and understand your frustrations. The world has changed.

<!-- -->