Native Image Inspection Tool

Native Image provides the inspection tool to list all methods included in a native executable or a native shared library. Run the command $JAVA_HOME/bin/native-image-inspect <path_to_binary> to list classes, methods, fields, and constructors in the JSON format that validates against the JSON schema defined in native-image-inspect-schema-v0.2.0.json.

Note: The inspection tool is not available in GraalVM Community Edition.

The native-image builder, by default, includes metadata in the native executable which then enables the inspection tool to list the included methods.

The amount of data included is fairly minimal compared to the overall image size, however you can set the -H:-IncludeMethodsData option to disable the metadata emission. Images compiled with this option will not be able to be inspected by the tool.

Software Bill of Materials (SBOM) #

Native Image can embed a Software Bill of Materials (SBOM) at build time to detect any libraries that may be susceptible to known security vulnerabilities. Native Image provides the --enable-sbom option to embed an SBOM into a native executable.

Note: Embedding a Software Bill of Materials (SBOM) is not available in GraalVM Community Edition. The feature is currently experimental.

The CycloneDX format is supported and the default. To embed a CycloneDX SBOM into a native executable, pass the --enable-sbom option to the native-image command.

The implementation constructs the SBOM by recovering all version information observable in external library manifests for classes included in a native executable. The SBOM is also compressed in order to limit the SBOM’s impact on the native executable size. Even though the tool is not yet supported on Windows, Windows users can still embed the SBOM with this experimental option. The SBOM is stored in the gzip format with the exported sbom symbol referencing its start address and the sbom_length symbol its size.

After embedding the compressed SBOM into the executable, the tool is able to extract the compressed SBOM using an optional --sbom parameter accessible through $JAVA_HOME/bin/native-image-inspect --sbom <path_to_binary> and outputs the SBOM in the following format:

  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "components": [
      "type": "library",
      "group": "io.netty",
      "name": "netty-codec-http2",
      "version": "4.1.76.Final",
      "properties": [
          "name": "syft:cpe23",
          "value": "cpe:2.3:a:codec:codec:4.1.76.Final:*:*:*:*:*:*:*"
          "name": "syft:cpe23",
          "value": "cpe:2.3:a:codec:netty-codec-http2:4.1.76.Final:*:*:*:*:*:*:*"
          "name": "syft:cpe23",
          "value": "cpe:2.3:a:codec:netty_codec_http2:4.1.76.Final:*:*:*:*:*:*:*"
  "serialNumber": "urn:uuid:51ec305f-616e-4139-a033-a094bb94a17c"

The tool can extract the SBOM from both executables and shared libraries. To scan for any vulnerable libraries, submit the SBOM to a vulnerability scanner. For example, the popular Anchore software supply chain management platform makes the grype scanner freely available. You can check whether the libraries given in your SBOMs have known vulnerabilities documented in Anchore’s database. For this purpose, the output of the tool can be fed directly to the grype scanner to check for vulnerable libraries, using the command $JAVA_HOME/bin/native-image-inspect --sbom <path_to_binary> | grype which produces the following output:

netty-codec-http2    4.1.76.Final   CVE-2022-24823  Medium

You can then use this report to update any vulnerable dependencies found in your executable.

Further Reading #

Connect with us