It seems like there’s a new major security hole patched in Java every other week, and I would assume the same goes for other development platforms. After years of frustration trying to get customers to install and configure a compatible JRE on their systems, we started bundling one with our software. (By bundling, I mean we extract a copy of the JRE in our installation directory–we don’t install the JRE and configure it as the system default.)
The problem is, it’s a hassle having to keep that JRE up-to-date because first we have to retest everything to make sure the update didn’t break anything (it has broken some of our third-party dependencies in the past).
How seriously, if at all, are we putting our customers at risk if we don’t update our SDK/JDK and the runtime/JRE that we bundle with our product every time there’s a security update? Is it reasonable to just update on a periodic schedule–say, once every 6 months or so?
12
That depends on the nature of the security holes and that of your application.
The most popular and major ones that have been fixed are related to applets. This is to say that there’s some hole in the Java stack (JVM, native libraries, Java libraries, etc.) that allows an applet to access e.g. files on disk, to run a process, the kind of things that applets shouldn’t be able to do.
If your application is a desktop application, I believe there is very little risk involved for a 6 months update interval. Most of the times, the kind of holes in desktop applications is tied to operating system holes, such as allowing a lower privilege application access a window from a higher privilege one. Or similarly, an application running in non-administrator being able to access an administrator’s application windows and process address space.
On the other hand, another application that the user runs with as much privilege as yours can do just about anything. Messing around with your application is not really the worse of things I can imagine, unless it can launch missiles or withdraw money.
EDIT: If your application is a server, then again some of the nasty vulnerabilities might pose a greater risk. We never know. Maybe there’s something in Java’s sockets that allows remote code execution, and so you’d consider this to be very high risk compared to delegating the update burden to your client.