harden GitHub Actions against supply chain attacks

[hu-ahmed]

Background

The https://www.stepsecurity.io/blog/harden-runner-detection-aqua-security-trivy-action-supply-chain-attack — where an attacker force-pushed 76 of 77 version tags in aquasecurity/trivy-action to malicious commits — showed that any CI workflow consuming third-party actions by mutable reference (tags, branches) is one upstream compromise away from shipping attacker code. Ditto's workflows were in that category.

This PR applies the hardening baseline recommended by the Eclipse Foundation Security Team in https://blog.mbarbero.com/ (Mikaël Barbero, 2026-03-24), adapted to Ditto's specific workflows.

What changed

1. Every third-party action pinned to commit SHA. 17 distinct actions across 10 workflows. Each uses: owner/name@vX is now uses: owner/name@ # . SHAs resolved and verified with https://github.com/suzuki-shunsuke/pinact (the tool cited in the Eclipse blog post) — not by hand. A tag can be silently repointed; a SHA cannot.

2. .github/dependabot.yml added. Weekly github-actions ecosystem updates, grouped into a single PR, with a 7-day cooldown so we don't adopt a compromised release during the first 24 hours of an incident. Config matches the Eclipse security team's template verbatim.

▎ Dependabot still needs to be enabled at the repo level (Settings → Security → Dependabot). The file alone is not enough — Eclipse Foundation admins can flip this on.

3. step-security/harden-runner added in audit mode to every GitHub-hosted job (9 workflows, 11 jobs). Records network egress and file modifications without blocking. Had this been active during the Trivy incident, exfiltration to the typo-squatted scan.aquasecurtiy.org domain would have been immediately visible. The self-hosted ditto-runner job in system-tests.yml is intentionally excluded — harden-runner is designed for GitHub-hosted runners and needs runner-owner validation before enabling.

4. Docker image pinned by digest. maven:3.9.12-eclipse-temurin-25 → maven:3.9.12-eclipse-temurin-25@sha256:4f82a03a... in all 4 uses in system-tests.yml. Container tags have the same mutability problem as action tags.

5. Supply-chain linters added/run:

• https://github.com/boostsecurityio/poutine run locally: zero failures on unpinnable_action, injection, default_permissions_on_risky_events, known_vulnerability_in_build_component, and all other blocking rules. The 6 note-level findings are informational flags on unverified-creator actions (dorny, helm, jitterbit, peaceiris) — widely used but not on GitHub's Marketplace verified list. No action required.
• https://github.com/zizmorcore/zizmor added as a new CI job (.github/workflows/zizmor.yml). Runs on every PR that touches .github/workflows/**, uploads SARIF to the GitHub Security tab. Currently in advisory mode (continue-on-error: true) — we'll flip it to gating in a follow-up PR once existing findings are cleaned up. This mirrors the "audit first, block later" pattern used for harden-runner.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.