Introduce Integrity verification for spring project jars in the Spring Boot gradle and maven plugins

[asaikali]

Supply chain security attacks are on the rise, see MavenGate Attack Could Let Hackers Hijack Java and Android via Abandoned Libraries for recent examples. Given the popularity of spring in the Java ecosystem, it would great to enhance the Spring Boot maven and gradle plugins to perform extra verification checks during the build to make sure that all packages under the org.springfarmework package hierarchy are authentic jars built by the Spring team.

The maven and gradle plugins should perform the following checks:

1. Verify that any jars files under the org.springframework group id were in fact built by the spring team. If the verification fails then the build should fail with an error message.
2. Scan all the other .jar files that are added to the the boot app to see if they contain code under the org.springfamework package hierarchy if they do then fail the build.

The exact verification mechanisms need to be be determined. I suggested we use Sigstore to sign all the spring jars. projects signed using sigstore can be validated against Rekor Sigstore and Rekor are industry standards for supply chain security.

[mhalbritter]

The artifacts published to Maven Central (and repo.spring.io) are already signed with GPG.

The key which signed them can be found here: https://spring.io/GPG-KEY-spring.txt

To verify an artifact with gpg, you'll need to do these steps:

1. fetch the jar: wget https://repo1.maven.org/maven2/org/springframework/boot/spring-boot/3.4.4/spring-boot-3.4.4.jar
2. fetch the signature wget https://repo1.maven.org/maven2/org/springframework/boot/spring-boot/3.4.4/spring-boot-3.4.4.jar.asc
3. Import the Spring GPG key: gpg --keyserver keyserver.ubuntu.com --recv 48B086A7D843CFA258E83286928FBF39003C0425 (you'd only need to do that once)
4. Verify the signature: gpg --verify spring-boot-3.4.4.jar.asc spring-boot-3.4.4.jar

Which should print something like this:

gpg: Signature made Do 20 Mär 2025 14:30:52 CET
gpg:                using RSA key 48B086A7D843CFA258E83286928FBF39003C0425
gpg: Good signature from "Spring Builds (JAR Signing) <builds@springframework.org>" [unknown]
gpg:                 aka "Spring Builds (JAR Signing) <buildmaster@springframework.org>" [unknown]
gpg:                 aka "Spring Builds (JAR Signing) <1134463+spring-builds@users.noreply.github.com>" [unknown]
gpg:                 aka "Spring Builds (JAR Signing) <spring-builds@vmware.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 48B0 86A7 D843 CFA2 58E8  3286 928F BF39 003C 0425

If we'd pin 48B0 86A7 D843 CFA2 58E8 3286 928F BF39 003C 0425 as trusted in our Gradle / Maven plugin, we could validate jar signatures for all Spring projects right now.

Point 2. from @asaikali is still an issue, though.

[wilkinsona]

We discussed this and consider it to be out of scope for the Spring Boot project.

Verify that any jars files under the org.springframework group id were in fact built by the spring team. If the verification fails then the build should fail with an error message.

Our position is that effective verification of an application's dependencies needs to be performed by the build system and should apply to all dependencies, not just those in or beneath the org.springframework group. Gradle already has such support and users could, for example, enable signature verification and trust our key for org.springframework.* dependencies.

Scan all the other .jar files that are added to the the boot app to see if they contain code under the org.springfamework package hierarchy if they do then fail the build.

We don't believe that this will improve an application's security as code doesn't need to be in the org.springframework package hierarchy to cause a problem. You could, instead, cause code in any package to run by using an entry point declared in META-INF/services or spring.factories. As with jar verification, for this risk to be addressed effectively it needs to be done for all dependencies. As such, the Spring Boot project isn't best-placed to address it.