Java 8

Use these rules for code that must stay on the supported Java SE 8 line. Compile-time types, annotations, and generics are modeling aids; enforce security properties again at each runtime trust boundary.

Runtime and deployment baseline

• Run the newest Java 8 security update from a vendor that still publishes them, recording the vendor, full build string, update channel, and license in deployment records. Replace every runtime, container layer, and bundled JRE on each vendor Java 8 security update, including those between quarterly Critical Patch Updates, building from a Java 8 line tag rebuilt with docker build --pull or a bot-updated digest. Where a Dockerfile, toolchain file, or CI matrix needs an exact update you can't check against vendor release notes, leave a build-failing placeholder.
• Dependency scanners don't see the JDK: scan built images with a container scanner, and have CI run java -version in the image and fail when your vendor lists a newer Java 8 security update. Oracle JDK 8 and OpenJDK 8 builds give the same security release different update numbers, so compare a build only with its own vendor's list.
• Confirm your Java 8 distributor still supports the operating system, TLS configuration, provider set, and third-party agents, and don't assume an Oracle support date or patch applies to another vendor's build.
• Prefer a current LTS for new systems. Where Java 8 is unavoidable, prevent compiling against later APIs and test the exact production JRE, not only a newer compiler's -target 1.8 output.
• Remove the browser plug-in, applet, Java Web