Chris,
From a technical perspective, we use InstallAnywhere, which is a system for packaging up and deploying applications across multiple platforms (hence Java-based). For Java applications like ours, IA packages a JRE in with the installer (to bootstrap itself, so you don't have to have a JRE installed to run their installers), and lets us select a JRE to deploy within our install process. IA also provides a launcher that lets you run a Windows service (or linux/unix daemon) that combines that deployed JRE with the bootstrap requirements of your application. The JRE is effectively only files dropped on the system as a part of an install - nowhere is the system $PATH modified or the full JRE installation ran (no annoying updater, no plugins), it's effectively just files placed on the filesystem. The Launcher then references that JRE directory to launch our application with the right libraries in the right places. If you update the system's JRE, it doesn't affect our JRE unless you intentionally replace ours, which you'd have to be well aware that you were doing (again, it's files on disk, you'd have to intentionally replace them with a new copy).
As far as vulnerabilities in the JRE goes, we quite honestly do make an attempt to update JREs regularly and have a system for doing so from the appliance to the agent, but we limit it to only when we update our agents. Our current JRE version is JRE 6u26 on windows, where the current version of 6 is 6u32 (we are not using Java 7 because we like to fully bake our agents to make sure they are rock solid, and Java 7 is a little fresh). (NOTE: As you might expect this info changes over time; as of May 2016 the agent is running Java 7u80, and we are working on moving to Java 8u92.) It is technically possible for customers with serious concerns to update the JRE independent of us, but you may run into compatibility issues that we have not tested, so we don't officially support doing so.
Your attack surface with that JRE dropped with the agent would be limited to things ran in that JRE's context. Out of the box, of course, the only thing that runs this JRE would be our agent. Since we don't register to the system environment, the browser, or install the (annoying) auto-updater dealie, it should be difficult without explicitly doing so to have another application run in our JRE.
Many JRE exploits these days are:
- Java Web Start: In order to be vulnerable here, you'd need a vulnerable JRE to automatically launch JWS ran applications. Since we don't register to the system, you'd have to do this on purpose.
- Java Applets: In this case, you'd need to run a vulnerable applet in the browser (or standalone) context. Since we don't register to the browser, you'd really have to work to do this one on purpose.
- Running unknown applications inside the JRE (a more generic version of the above): things like Tomcat and other servlet containers can have issues because vulnerable applications can expose the system if exploitable. Since our application is the only thing that runs with the JRE, this wouldn't apply.
- Remote vulnerabilities at the protocol or process level: since our agent isn't acting as a "server" for anything, it'd only be a risk if you were using the same JRE as a service for something else. You'd have to work to make this happen.
It's worth noting that the agent doesn't listen for inbound connections, it makes an outbound connection to the appliance. The communication between the appliance and the agent is all encrypted.
When Java was a big deal in web browsers they used to try to scan the system for available JREs. In that situation, an enterprising user interested in running the latest annoying navbar (it probably blinked in neon green and linked to their webring, too), could have hooked up to an arbitrary JVM. These days, browsers are pretty keen on plug-ins, and have been burned enough by Java to be careful.
We have had customers with strict server versioning requirements turn up our JRE in a scan by software inventory or other tools and comment that it's out of date, and like I said we do make an attempt to update it as we can, or address concerns about any potential vulnerabilities specific to the release version we've got on disk.
Regardless of all of that, I hear you on the agent vs. agentless issue, which is a time honored debate, and something we do continue to keep our eye on.