• Home
• Dev
• Security Guide

Security Considerations in Native Image

The native-image builder generates a snapshot of an application after startup and bundles it in a binary executable. The security report section of the native image build output provides security relevant information about the native image build.

Class Initialization #

The native-image builder may execute the static initializers of certain classes at build time (see class initialization for more details). Executing static initializers at build time persists the state after initialization in the image heap. This means that any information that is obtained or computed in static initializers becomes part of a native executable. This can either result in sensitive data ending up in the snapshot or fixing initialization data that is supposed to be obtained at startup, such as random number seeds.

Developers can request static initializers that process sensitive information to be executed at run time by specifying the --initialize-at-run-time CLI parameter when building a native executable, followed by a comma-separated list of packages and classes (and implicitly all of their subclasses) that must be initialized at runtime and not during image building. Alternatively developers can make use of the RuntimeClassInitialization API.

Developers should run the native-image builder in a dedicated environment, such as a container, that does not contain any sensitive information in the first place.

Software Bill of Materials #

Native Image can embed a Software Bill of Materials (SBOM) which is an inventory of all the components, libraries, and modules that make up an application. Read more in Software Bill of Materials (SBOM) in Native Image.

Java serialization in Native Image #

Native Image supports Serialization to help users deserialize the constructors for classes, contained in a native executable. Unless picked up by native image analysis automatically, these classes have to be prespecified, as classes not contained in a native executable cannot be deserialized. Native Image cannot prevent exploitation of deserialization vulnerabilities in isolation. The serialization and deserialization Secure Coding Guidelines for Java SE should be followed.

The security report section of the native image build output provides information on whether deserialization code is part of a native image’s attack surface or not.

Miscellaneous #

Setting the security manager is not allowed. For more information see the compatibility documentation.

Native Image provides multiple ways to specify a certificate file used to define the default TrustStore. While the default behavior for native-image is to capture and use the default TrustStore from the build-time host environment, this can be changed at run time by setting the “javax.net.ssl.trustStore*” system properties. See the documentation for more details.

The directory containing the native executable is part of the search path when loading native libraries using System.loadLibrary() at run time.

Native Image will not allow a Java Security Manager to be enabled because this functionality has now deprecated since Java 17. Attempting to set a security manager will trigger a runtime error.

Related Documentation #

• Security Guide
• Sandboxing
• Jipher JCE with Native Image