A CI runner downloads a JDK before it can compile or test anything. If that artifact is not verified, the build trusts bytes fetched from the network at one of the earliest and most powerful points in the pipeline.

Quick answer

Upgrade to actions/setup-java v5.5, enable signature verification where supported, pin the action according to your organization policy, and test Maven caches and settings in a branch before changing protected workflows.

- uses: actions/setup-java@v5.5.0
  with:
    distribution: temurin
    java-version: '21'
    check-latest: false

what changed

Version 5.5 adds cryptographic signature verification for downloaded JDKs, support for the Kona distribution, and Maven-related fixes. Signature checks add provenance evidence beyond a successful download.

This is a current platform change, so confirm availability for your plan, organization, and installed client before changing a production workflow. Preview features can also change faster than generally available controls.

who should use it

The change matters for repositories that fetch a JDK on every clean runner. It is one layer of defense: workflow permissions, pinned actions, protected branches, and dependency verification still matter.

The practical question is whether the feature removes a real bottleneck or security gap in your workflow. A new control is not valuable merely because it exists; it needs an owner, a narrow purpose, and an observable result.

a safe implementation

  1. Read the distribution-specific verification requirements.
  2. Upgrade in a pull request with an empty cache run.
  3. Confirm Maven credentials and mirrors still work.
  4. Pin the final action reference using team policy.

Make the first rollout small enough to reverse. Record the previous behavior, the setting or command that changed it, and the person responsible for deciding whether the experiment expands.

the mistake to avoid

Do not assume a version tag is immutable merely because it looks precise. Security-sensitive organizations often pin actions to a reviewed commit SHA and use automation to propose updates.

Convenience features still operate inside your existing trust model. Repository permissions, protected environments, review rules, test accounts, and audit logs remain important even when the new workflow removes manual steps.

how to verify it

Run the workflow on a clean hosted runner, record the installed JDK vendor and version, and inspect logs for successful verification. Build and test a real module rather than stopping after Java installation.

Keep the verification evidence in the pull request or rollout ticket. That gives reviewers something concrete to evaluate and gives the next person a known baseline when the platform changes again.

rollout checklist

  • Confirm the feature and client version are available.
  • Test with non-production data and minimum permissions.
  • Capture expected success and failure behavior.
  • Document rollback and ownership.
  • Recheck the official announcement before a wide rollout.

official reference

The announcement is the source of truth for availability and product behavior. This article focuses on the implementation decisions teams should make around it.