Add Sigstore dependency verification for Maven and Gradle

[yogurtearl]

Feature request

Please add first-class Maven and Gradle support for verifying Sigstore signatures of project dependencies.

The existing integrations focus on signing artifacts. It would be useful to support the consumer side as well: verifying the dependencies a build resolves before they are used.

Desired behavior

The Maven and Gradle integrations should be able to:

• Verify all resolved dependencies, including transitive dependencies.
• Locate the corresponding .sigstore.json bundle.
• Verify the artifact and Sigstore bundle using sigstore-java.
• Enforce trusted signer identities, including OIDC issuer and certificate identity.
• Fail the build when verification fails.
• Clearly report the dependency coordinate and reason for failure.
• Verify cached dependencies as well as newly downloaded artifacts.

It would also be useful to configure how unsigned dependencies are handled:

missingSignature = fail | warn | ignore

Signer policies could optionally be scoped by Maven coordinates, for example:

com.example:*:
  issuer: https://token.actions.githubusercontent.com
  identity: https://github.com/example/project/.github/workflows/release.yml@*

Maven / Gradle integration

For Maven, this could be implemented in sigstore-maven-plugin or through Maven Resolver if dependency-resolution hooks are needed.

For Gradle, it could integrate with dependency resolution and complement Gradle's existing dependency verification support.

The goal would be for normal build commands such as:

mvn verify
./gradlew check

to enforce Sigstore verification automatically.

Motivation

This would make Sigstore useful for both sides of the supply chain:

publishers sign artifacts → repositories distribute them → Maven/Gradle verify them before use

It would avoid requiring custom cosign scripts or bespoke build logic.

[loosebazooka]

Yeah this is a great point. I think we don't have a good verification story at the build tool level.

There was previously a plan to do this directly in gradle like the verification-metadata, but we never got around to it. Before we ask them again it's probably meaningful for us to prove a few thing:

1. We have some meaningful plugin level prototypes that users can use.
2. We are seeing increased adoption on maven central.
3. There is a standard verification format across language ecosystems.

(1) and (2) don't depend on each other. So maybe we can start with (1) and see where we get. (3) is somewhat important for the health of the project so we want to get it right, but it shouldn't prevent us experimenting.

I'll take a look at your suggestions and see what we can come up with.