Maven Security & Reproducible Builds

The Maven security page starts from one sentence: Maven performs the actions defined in the pom.xml, which usually means compiling and running code and using plugins and dependencies from the configured repositories, so the security model assumes you trust the pom.xml and the code, dependencies and repositories that are used in your build. Building untrusted code safely is left to you, through isolation (a container, a throwaway virtual machine, a build without credentials).

Source: Maven: Security Model

The same page lists the published vulnerabilities. They show where Maven did harden itself:

Source: Maven: Security Vulnerabilities

The page adds that no binary patches are produced for individual vulnerabilities: to get a fix you upgrade to a Maven that contains it. The 2026 hardening of Maven 3.10 is described (and run) below.

Maven’s checks on a download are the repository layout and the checksum files next to each artifact; the rest is policy that you configure.

What Maven does not do is verify PGP signatures of what it downloads. That is demonstrated after the next section, which shows how artifacts are signed.

On a project that you build with untrusted plugins there is another place for a guard: the Enforcer can ban plugins (bannedPlugins) and repositories (bannedRepositories, requireNoRepositories) and require pinned plugin versions (requirePluginVersions).

Maven Central requires every artifact to carry a PGP signature (see Publishing to Maven Central), and other repositories may too. The gpg:sign goal signs all the attached artifacts of a project with GnuPG and attaches the .asc files, so that install and deploy publish them next to the files. Sign in a profile so that day-to-day builds do not need a key:

Source: Sign artifacts with GnuPG

The documented way to hand the passphrase to a batch build is the environment variable MAVEN_GPG_PASSPHRASE (the name is the passphraseEnvName parameter); on a workstation prefer gpg-agent. The plugin’s own documentation discourages a passphrase on the command line, in settings.xml or in the POM, and bestPractices set to true makes the build fail if one of those is used. loopback pinentry is what lets gpg take the passphrase from the environment instead of opening a dialog.

Source: Security considerations

The 3.10.0 release notes list, under "Security Hardening", that a model resolved from a repository (a dependency, a parent or an imported BOM) "contributes less to the build": restricted interpolation, profile activation limited to platform-derived criteria, recessive repository merging and rejection of system-scoped dependencies, with the property maven.model.dependencyInterpolation.full as an opt-out. The point is that a POM you download is data from someone else: it should not read your environment or your files. To see what that means, small libraries were deployed to a repository on disk (<work>/restricted/repo, with deploy:deploy-file) and a consumer project depended on one of them. Each library has a POM with one questionable feature; the tree is printed with dependency:tree. (The consumer’s own POM is not restricted; only models read from a repository are.)

Source: Maven 3.10.0 release notes: Security Hardening

The first library, lib-interp, declares a dependency on io.tidepool.lab:helper whose version is ${env.TIDEPOOL_HELPER_VERSION}, an environment variable. With TIDEPOOL_HELPER_VERSION=1.0 set, the filtered output of mvn dependency:tree on Maven 3.10.0 shows that the placeholder is no longer resolved:

On Maven 3.9.16 the same project resolved helper 1.0 (the environment variable was used to choose a version, which is how a repository POM could have influenced your build from your environment). With -Dmaven.model.dependencyInterpolation.full=true on Maven 3.10.0 the old behaviour came back and helper:jar:1.0 was in the tree. On Maven 4.0.0-rc-7 helper was simply not in the tree and the build succeeded.

The other libraries test the profile activation of a POM that comes from a repository. Each library has a profile that adds helper:2.0 when it is active; the table says whether helper 2.0 was in the tree:

So a repository POM can no longer activate a profile because a file exists on your disk, which is the kind of probing that profile activation allowed, while the JDK and the properties you pass yourself on the command line (the user properties) still activate profiles. Another library declared a dependency with <scope>system</scope> and <systemPath>/etc/hosts</systemPath>. The release notes list the rejection of system-scoped dependencies from such models, but in this run it was not rejected: the dependency was in the tree and dependency:build-classpath printed .../lib-system-1.0.jar:/etc/hosts on both 3.9.16 and 3.10.0, and also in the tree of 4.0.0-rc-7. Do not rely on 3.10 to block that case; system scope is deprecated anyway (see Dependencies, Scopes & Mediation).

Because Maven trusts the project, merely running mvn in a directory you did not write can run its code: the plugins of the POM, but before that, the files of the .mvn directory (see Configuring Maven). A project with only a POM and two lines in .mvn:

Both values were set by files of the project, without anything on the command line. maven.config adds command-line options and jvm.config options of the JVM that runs Maven, so a hostile jvm.config could name a Java agent, and a hostile .mvn/extensions.xml makes Maven download and load a core extension before the build starts (see Extensions). The prudent practice is the one of the security model: review those files and the POM before building a project from a stranger, and build it in an isolated environment with no credentials (settings.xml, tokens and keys) in reach.

A software bill of materials lists the components of a build so that a later advisory can be matched against it. The CycloneDX Maven plugin (a third-party plugin of the CycloneDX project, 2.9.3 on Central) creates one. It is shown, with the other tools' SBOMs and the format, in Supply Chain Security; here is only what it adds to reproducibility. makeBom was run on tidepool-engine twice, two seconds apart, with JSON output, and the two files compared with diff:

On Maven 3.10.0 the file is byte for byte the same (it has no timestamp in its metadata; its serialNumber was the same in every run on both Maven versions), on 3.9.16 the only difference is the creation time. So under 3.10’s reproducible default the SBOM can be compared and signed like any other output. Its purl entries listed commons-csv 1.14.1, commons-io 2.20.0 and commons-codec 1.19.0 as the dependencies of the engine.

Source: CycloneDX Maven plugin

An SBOM does not tell you which components are vulnerable; a scanner compares it, or the dependency tree, with a vulnerability database. The OWASP Dependency-Check Maven plugin (13.0.0 on Central) is the well-known one; it needs to download the NVD data (rate-limited without an API key), so it was not run here. The Enforcer’s third-party Sonatype OSS Index rule (see Enforcer) queries an online service and was not run either. Run scanners in CI against the dependency tree, look at what is really in the tree with Dependency Analysis & Convergence, and pin what you accept with Dependency Management & BOMs.

A build is reproducible when the same sources, build environment and build instructions give bit-by-bit identical files, so that anyone can rebuild a published release and compare. Maven’s contribution is project.build.outputTimestamp, the single timestamp that its archive plugins write into every entry; since Maven 3.10.0 the super POM sets it (to 1980-02-01T00:00:00Z), so all projects are in the reproducible mode (see Packaging: JARs, WARs & Manifests, which also has the first artifact:compare runs). That is the necessary part, not the sufficient one. The official guide says what still leaks into the output: plugins that do not support the timestamp, dependency version ranges, different line endings on Windows and Unix, and the major version of the JDK that compiled the classes.

Source: How to fix my Maven build reproducibility?

Source: Gradle: the Signing plugin

Source: Gradle: reproducible archives

The cross-tool picture is in Comparing Ant, Maven and Gradle.