security: pin GitHub Actions to SHA digests via Renovate

[stevendborrelli]

Description

Configures Renovate to automatically pin GitHub Actions to SHA256 digests for improved supply chain security.

Security Benefits

Tag/Branch Hijacking Protection

• Problem: GitHub Actions tags and branches are mutable and can be changed to point to malicious code
• Solution: SHA digests are immutable references to specific commits
• Impact: Prevents compromised tags from affecting our CI/CD pipeline

Supply Chain Security Best Practices

Aligns with industry security standards:

• ✅ SLSA Level 3: Requires pinned dependencies
• ✅ OpenSSF Scorecard: Recommends pinning actions by hash
• ✅ NIST SSDF: Implements secure dependency management

Example Transformation

Before (vulnerable to tag hijacking):

- uses: actions/checkout@v4

After (pinned to specific commit):

- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

How It Works

1. Renovate will automatically update GitHub Actions
2. Each action will be pinned to its SHA256 digest
3. Human-readable version comments will be preserved (e.g., # v4.1.1)
4. Updates will be grouped together in a single PR

Changes

Added to renovate.json:

{
  "matchManagers": ["github-actions"],
  "pinDigests": true,
  "groupName": "GitHub Actions"
}

Testing

After merge, Renovate will automatically:

1. Scan all workflow files in .github/workflows/
2. Create a PR pinning actions to SHA digests
3. Keep actions up-to-date while maintaining security

References

• SLSA Supply Chain Security
• OpenSSF Scorecard - Pinned Dependencies
• GitHub Security Best Practices
• Renovate Pin Digests Documentation

I have:

• Read and followed Crossplane's contribution process
• Configured Renovate for improved supply chain security

[humoflife]

In renovate.json — should we add "helpers:pinGitHubActionDigests" to extends? That's the upstream-maintained preset (crossplane/crossplane extends it too) and it replaces the hand-rolled pinDigests rule with a narrower matchDepTypes: ['action'] match.

In .github/workflows/ci.yml (lines 115 and 147) — should we pin https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh to a release tag instead of master? Right now we pipe an unpinned script from a moving branch into sh in the job that holds XPKG_TOKEN, which keeps the Supply-chain Levels for Software Artifacts (SLSA) L3 / Scorecard "Pinned-Dependencies" goals from being met.

L3 looks at if the build platform is hardened: builds run in isolated, ephemeral environments, and the signing key is inaccessible to user-defined build steps, so provenance is unforgeable. In GitHub Actions terms that usually means generating provenance via a trusted reusable workflow (e.g. slsa-framework/slsa-github-generator) rather than inside our own job.

[stevendborrelli]

@humoflife let's create a separate issue to address the other comments:

In renovate.json — should we add "helpers:pinGitHubActionDigests" to extends? That's the upstream-maintained preset (crossplane/crossplane extends it too) and it replaces the hand-rolled pinDigests rule with a narrower matchDepTypes: ['action'] match.

In .github/workflows/ci.yml (lines 115 and 147) — should we pin https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh to a release tag instead of master? Right now we pipe an unpinned script from a moving branch into sh in the job that holds XPKG_TOKEN, which keeps the Supply-chain Levels for Software Artifacts (SLSA) L3 / Scorecard "Pinned-Dependencies" goals from being met.

L3 looks at if the build platform is hardened: builds run in isolated, ephemeral environments, and the signing key is inaccessible to user-defined build steps, so provenance is unforgeable. In GitHub Actions terms that usually means generating provenance via a trusted reusable workflow (e.g. slsa-framework/slsa-github-generator) rather than inside our own job.