Supply-Chain Security for JVM Builds

The Apache download pages publish, next to every archive, a .sha512 file, an .asc PGP signature and a KEYS file with the release managers' public keys. Both projects tell you to verify the signature and say the checksum is the weaker of the two checks; Ant’s page adds that you should take the KEYS and .asc files from the main distribution directory rather than from a mirror.

Ant 1.10.18 and Maven 3.10.0 publish the .sha512 file as the bare hexadecimal digest, with no file name, so the shasum -c mode needs the name added. The check below was run against the Maven 3.10.0 archive that this series downloaded and verified, and then against a copy with one byte changed:

The PGP step, as the Ant download page describes it, is gpg --import KEYS followed by gpg --verify of the .asc file (Ant’s own KEYS file is also inside its binary distribution, and gpg 2.2.41 was available here). The signature check itself was not run here, because this series downloaded only the archives and checksums. A signature proves the archive was produced by a holder of one of the listed keys, so the remaining question is how you came to trust KEYS: download it over HTTPS from downloads.apache.org, and compare key fingerprints with the Apache web of trust when the stakes justify it.

Source: Ant: Binary Distributions, Verify Releases

Source: Maven: Downloading Apache Maven

Gradle publishes a SHA-256 checksum for each distribution on its release-checksums page and next to the file on services.gradle.org. The checksum file for 9.8.1 used here is gradle-9.8.1-bin.zip.sha256; the value of the distribution this series downloaded matched the one published for 9.8.1:

For the wrapper, Gradle ships the checking as a feature: the next section shows it. Gradle’s security best practices list both "validate the Gradle distribution SHA-256 checksum" and "validate the Gradle Wrapper on every upgrade" as recommended practices.

Source: Gradle: release checksums

Source: Gradle: Validate the Gradle Distribution SHA-256 Checksum

The Ant 1.10.18 binary distribution carries a CycloneDX SBOM for every JAR in lib, in JSON and XML next to the JAR, and the download page lists .cdx.json files next to each archive. The distribution unpacked here has 26 such JSON files.

Source: Ant: Binary Distributions

gradle-wrapper.properties accepts distributionSha256Sum. When it is set, the wrapper hashes the downloaded archive and refuses to continue on a mismatch. The wrapper task writes it when you pass --gradle-distribution-sha256-sum (a task option confirmed with gradle help --task wrapper on 9.8.1; the other options listed are --gradle-version, --gradle-distribution-url, --distribution-type, --validate-url, --network-timeout, --retries and --retry-back-off-ms).

The example uses a wrapper directory whose distributionUrl points to the local copy of the 9.8.1 archive (to avoid a second download) with a deliberately wrong checksum:

The official properties for 9.8.1 differ only in the two lines that point at https://services.gradle.org/distributions/ and in validateDistributionUrl=true. distributionSha256Sum protects the archive. It does not protect the other executable pieces in the repository, gradlew, gradlew.bat and gradle/wrapper/gradle-wrapper.jar, which run before any of that checking happens. The JAR’s own checksum is published by Gradle, and the 9.8.1 value matched the one in the scratch project:

Source: Gradle: Verifying the integrity of the Wrapper

Source: Gradle: Validate the Gradle Wrapper on every Upgrade

The Maven Wrapper (plugin 3.3.4, the version on Maven Central on the check date) generates .mvn/wrapper/maven-wrapper.properties. The file generated here with wrapper:wrapper -Dmaven=3.10.0 contained only the download location, no checksum:

The generated mvnw script reads an optional distributionSha256Sum and compares it with sha256sum or shasum -a 256. Adding the property is a manual step (the value to use is the SHA-256 of the zip; neither the Maven download page nor Maven Central publishes one, both publish SHA-512, so compute it once from an archive you verified with the SHA-512 and PGP steps above). The run below used a local zip of the verified distribution so that nothing was downloaded; first with a wrong value, then with the right one. MAVEN_USER_HOME points the wrapper’s download cache to the scratch directory:

Everything said above about the unprotected pieces applies to Maven too: mvnw is a shell script that runs before the checksum is checked, so review changes to it like code.

Source: Maven Wrapper: Checksum verification of downloaded binaries

Plain HTTP lets anyone between you and the repository replace an artifact. Both tools now refuse it by default, and the refusal is visible in a real error.

Maven. Since 3.8.1 (the fix for CVE-2021-26291, below) the default conf/settings.xml contains a blocked mirror for every external repository that uses HTTP. The relevant part of the file shipped in 3.10.0:

A POM that declares an HTTP repository (http://repo.example.org/maven2, never contacted because it is blocked) and a dependency that is only there fails with the same message on Maven 3.10.0, 3.9.16 and 4.0.0-rc-7:

external:http:* (a selector available since Maven 3.8.0) matches all repositories using HTTP except those on localhost, which is why a local test server on http://localhost is not blocked. Fix the repository (use its HTTPS URL), do not delete the blocker.

Gradle. A repository with an http: URL is rejected unless you opt in with allowInsecureProtocol = true (isAllowInsecureProtocol in the Kotlin DSL). The build below uses http://localhost:8081/... — Gradle does not exempt localhost — and no opt-in:

The Groovy build fails with the same message (not re-run separately: the repository declaration is the only difference).

Ant and Ivy. Neither has a policy: the URL you write is the URL used. <get src="http://..."> and an Ivy ibiblio resolver with an http root work without complaint, so the only defence is to write https and to review every repository URL in ivysettings.xml and build.xml. Ant 1.10.16 added TLS identity checks for the mail task, and 1.10.18 changed the ftp default (below); verifying what you fetched (next section) is your build’s job.

Source: Maven 3.8.1 Release Notes

Source: Maven: Guide to Mirror Settings

Source: Gradle DSL: UrlArtifactRepository.allowInsecureProtocol

Every repository publishes checksums next to its files. For commons-csv-1.14.1.jar on Maven Central the files .sha1, .md5 and .asc exist and .sha256 and .sha512 returned 404 on the check date (other artifacts can differ, so look before relying on an algorithm). The tools differ in how strictly they use these files:

Both behaviours were checked here against a file: repository whose .jar.sha1 was deliberately wrong: Maven 3.10.0 logged the ChecksumFailureException as a warning, resolved the JAR and printed BUILD SUCCESS, while Maven 4.0.0-rc-7 stopped with Checksum validation failed and BUILD FAILURE. So on Maven 3 only --strict-checksums turns these checks into something that stops a corrupted download. Even then, because a repository that serves a tampered JAR can serve a matching checksum, repository checksums catch corruption, not tampering. The two layers that follow compare against values the repository does not control.

Ant: verify what you fetch. The target below downloads a JAR and the SHA-1 file Central publishes next to it, and fails the build when they differ. It was run with Ant 1.10.18; the second target changes one byte of a copy to show the failure. The check only proves the download was not damaged, since both files came from the same server:

For a check that does protect you, put the expected value in the repository (a checksums.properties file loaded with <property file=...>) instead of downloading it from the server you are checking.

Source: Ant: Checksum task

Source: Ant: Get task

Ivy: checksum algorithms. The resolver in ivysettings.xml lists the algorithms to check. With the default, the -d output of an ivy:retrieve run shows each file checked:

Asking Ivy for a stronger algorithm needs the Java algorithm name. With the lowercase checksums="sha256" the resolution fails:

checksums="SHA-512" (and likewise SHA-256) is accepted, and Ivy 2.6.0 then asks for a file named after the algorithm, .pom.SHA-512 and .jar.SHA-512. Central has no such files, and a checksum file that is not found is not an error, so the same ivy:retrieve -d run ends in BUILD SUCCESSFUL with nothing verified (no OK for line in the whole log; trimmed to the commons-csv lines):

So against Maven Central the practical options with Ivy are SHA-1 and MD5 from the repository, plus your own <checksum> verification of the files you retrieve; a SHA-256 or SHA-512 list only helps with a repository that publishes files under those names. Ivy can also sign artifacts it publishes (the resolver signer attribute, since 2.2); the settings reference describes signers only for publication.

Source: Ivy: resolvers, the checksums attribute

Source: Ivy: signers

The Maven Resolver can pin every resolved artifact to a checksum you hold. The post-processor has two modes: record, run once in an environment you trust, writes a file of SHA-512 values; and verify, the normal mode, compares every resolved file with the file and fails the build on a mismatch or, with failIfMissing, on an unknown artifact. Commit the file to the repository so that the pinning survives a poisoned local repository or repository manager. The feature exists in Maven 3.9.x (Resolver 1.9) and in 3.10 and 4; this run used 3.10.0.

.mvn/maven.config of the tidepool-engine project (one option per line; the ${session.rootDirectory} expression needs Maven 3.9 or later):

The POM declares commons-csv:1.14.1 and pins the compiler and resources plugins. Recording against an empty local repository (-Dmaven.repo.local points to a scratch directory so that nothing but the build’s own downloads is recorded):

The file has one line per resolved artifact, SHA-512 first and the path relative to the local repository second (100 lines here, covering the plugins and their dependencies as well as the project’s own dependency). A normal build with a fresh local repository passes (BUILD SUCCESS). Changing the first two hexadecimal digits of the commons-csv-1.14.1.jar line makes the build fail, with both values in the message:

(PROVIDED) is the Resolver’s name for the checksum strategy that came from your file rather than from the repository. The Resolver also has a sparse-directory source (one checksum file per artifact, in a tree that mirrors the local repository) for repositories where one summary file per remote repository would be unwieldy; the Resolver documentation compares the two sources. Trusted checksums are a Maven-side equivalent of Gradle’s dependency verification (next), with SHA-512 and no signature support.

Source: Maven Resolver: Trusted Checksums

Source: Maven Resolver: Configuration, trustedChecksums

When a build lists several repositories, Maven asks them in order, so a repository that should never serve a given artifact can serve it first (dependency confusion), and every miss leaks the coordinates you build to that repository’s operator. Remote repository filtering (RRF) tells the Resolver which repository may serve which artifact. The Resolver 2 documentation, which Maven 3.10 and 4 use, describes two filters: prefixes, a list of path prefixes that the repository itself publishes, discovered automatically; and groupId, a file you write. The prefixes filter is why a Maven 3.10 build against Central prints a line like this on the first resolution:

A groupId file for the repository central is groupId-central.txt in the filter directory (set here with -Daether.remoteRepositoryFilter.groupId.basedir=${session.rootDirectory}/.mvn/rrf/ in .mvn/maven.config). A line is a group and everything below it; ! negates, = limits to exactly that group, and * sets the default to "accept". This file blocks the Apache Commons group on Central and allows everything else:

Building tidepool-engine, which depends on commons-csv, with a fresh local repository on Maven 3.10.0:

In real use the file lists the groups a repository is allowed to serve (for an internal repository, your own group ids), and Central is left alone: the Resolver documentation warns that limiting what can come from Central is risky because plugins and their dependencies come from it too. The Resolver can also record the group ids it meets (-Daether.remoteRepositoryFilter.groupId.record=true) as a starting point for such a file.

On Maven 3.9.16 (Resolver 1.9) the same file behaved differently: with no extra option the build passed (no filtering happened), and with -Daether.remoteRepositoryFilter.groupId=true it failed on the first plugin, saying that G:org.apache.maven.plugins was not allowed from central — the * default-accept line did not have the effect it has on 3.10. This page therefore uses 3.10 for the example; on 3.9.x enable the filter explicitly and list every group allowed.

Source: Maven Resolver: Remote Repository Filtering

Gradle’s feature is the most complete of the three. A file gradle/verification-metadata.xml lists the checksums (SHA-256 and others) and the PGP keys that are acceptable for each artifact; Gradle checks every dependency, plugin and metadata file it downloads against it, fails the build on a mismatch, and by default verifies the metadata files (.pom, .module) as well. The examples below were run on Gradle 9.8.1 only. The modes are --dependency-verification strict (default), lenient (report but do not fail) and off.

Maven itself does not verify PGP signatures of dependencies. Central requires signatures on published artifacts (see the Central requirements and Publishing to Maven Central), but the consumer side is up to extensions. A third-party plugin exists for that (the PGPVerify Maven plugin, a separate project that this series did not run); the first-party answer for Maven is the trusted-checksums mechanism above. Ant and Ivy have no built-in signature verification either, so for them verify with your own gpg --verify step in the build or in CI.

Source: PGPVerify Maven plugin (third party)

Credentials live in ~/.m2/settings.xml <server> entries matched to a repository by <id>. Three Maven-specific layers protect them:

Maven 3.10 added full settings.xml interpolation, which is what makes ${env.REPO_TOKEN} work for all values.

Source: Maven: Password Encryption

Source: Maven 4: Password Encryption

Source: Maven 3.10.0: Settings Reference, server

Declare the credentials by type and let Gradle look the values up from properties named after the repository. For a repository called internal the properties are internalUsername and internalPassword, which come from ~/.gradle/gradle.properties, the command line (-P) or, in CI, environment variables named ORG_GRADLE_PROJECT_internalUsername and ORG_GRADLE_PROJECT_internalPassword. The build file contains no secret and no property is read until the repository is used:

Without the properties, both builds stop with a message that names them:

With placeholder values supplied through the environment and a local server on port 8443 that answers in plain text (so the TLS handshake fails, localhost only), the build does not fall through to the second repository. It fails on the first one, which is the behaviour the security fix in Gradle 9.8.1 guarantees (see the advisories below):

The older behaviour (continuing with mavenCentral() after such an error) could not be run here, because Gradle versions before the fix were not installed.

Gradle 9.8.0 added reuse of Maven mirror settings (org.gradle.mirror.maven.settings=true), so a single internal mirror configuration in settings.xml serves both tools; the credentials-by-property mechanism above is unaffected.

Source: Gradle: Handling credentials

Ant has no credential store: the get task takes username and password attributes, and tasks such as scp take their own, so pass them as properties from the command line (-Drepo.password=...) or from a properties file outside the repository, never literals in build.xml. Ivy settings declare a credentials element with host, realm, username and passwd attributes, and the file that holds them should not be committed either.

Source: Ivy: credentials

The Antlib (released 2026-09-25, on Maven Central as org.apache.ant:ant-cyclonedx) provides a componentbom task and the types component, license, organization and others; it needs Ant 1.10.x (not guaranteed before 1.10.18) and Java 9 or later at run time, creates CycloneDX 1.7 by default, and can read Ivy files through an ivyModule resolver. For a project with manual dependency management you list the components yourself. The Antlib and its dependencies (CycloneDX Core Java, Jackson and others, 13 JARs) were fetched into a lib directory with the Maven dependency plugin from the ant-cyclonedx coordinates, then used with ant -lib lib:

The outputDirectory must exist (a first attempt without the mkdir failed with "outputDirectory must point to a directory"), and exactly one nested component is the subject of the SBOM, with further components declared through additionalComponent. Running it and listing the package URLs:

The first purl is the Antlib itself, recorded in the SBOM’s metadata.tools section. The SBOM contains commons-csv because the build file says so, not because anything scanned the classpath: with Ant the SBOM is only as accurate as the list you maintain, or as the Ivy descriptor you point it at.

Source: Apache CycloneDX Antlib

Source: CycloneDX Antlib: componentbom

Source: Ant: Binary Antlibs, release list

The CycloneDX Maven plugin is a third-party project (2.9.3 on Maven Central on the check date). makeBom can be run without touching the POM:

(Two warnings about unknown JSON-schema keywords, printed by the plugin’s validator between the JSON lines, are omitted from this output; they did not affect the result.) Both transitive dependencies of commons-csv appear, which the Ant SBOM above does not list because nothing told it about them. To produce the SBOM on every build, bind the goal to a phase in the POM; the attaching as lines show that the files are attached to the project and therefore installed and deployed with it. A multi-module project uses makeAggregateBom.

Source: CycloneDX Maven plugin (third party)

Source: CycloneDX

The CycloneDX Gradle plugin (plugin id org.cyclonedx.bom, 3.5.1 on the Gradle Plugin Portal on the check date, also third party) adds a cyclonedxBom task. Setting the project’s group and version avoids the plugin’s warning that it will otherwise use "unspecified".

The Groovy DSL build produced bom.json and bom.xml in the same directory (checked with ls; its contents were not compared). The resolution is that of the build’s runtime classpath, so the transitive dependencies are listed; whichever tool creates it, an SBOM generated at build time from the resolved graph is more trustworthy than one maintained by hand.

Source: CycloneDX Gradle plugin (third party)

The Maven 3.10.0 release notes list these under "Security Hardening":

The same release raises POM validation (duplicate plugins or dependencies, invalid characters in versions and others now fail the build; -Dmaven.resolver.validation=OFF (upper case; off fails with No enum constant) relaxes the new coordinate validation for a migration), makes reproducible builds the default (the super POM sets project.build.outputTimestamp) and changes the classpath order to breadth-first (-Daether.system.dependencyVisitor=preOrder restores the old order). The validation and ordering changes are not security fixes but matter when you upgrade: see Maven Security & Reproducible Builds.

Source: Maven 3.10.0 Release Notes

Source: Maven: Security Reports