Harden GitHub Actions supply chain - #143
Conversation
Pin all action references to full commit SHAs with semver comments, following the convention already used in pullrequest-labeler.yml. A mutable tag such as v7 can be repointed by the upstream owner, so a compromised action repository would execute in this repo's CI without any change landing here. Group Dependabot security updates per ecosystem so that a batch of vulnerability fixes arrives as one reviewable pull request instead of many. Version updates stay ungrouped to keep routine bumps individually revertible.
|
Warning Review limit reached
Next review available in: 31 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR hardens the CI supply chain by eliminating mutable GitHub Actions tag references and batching Dependabot security updates, reducing the risk of upstream action tag repoints and decreasing PR noise from vulnerability fix rollups.
Changes:
- Pinned all GitHub Actions
uses:references in workflows to full commit SHAs with semver comments. - Pinned CodeQL
init/analyzeactions to a commit SHA (instead of a mutablev4tag). - Added Dependabot grouping for security updates only (per ecosystem), leaving version updates ungrouped.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
.github/workflows/maven.yml |
Pins checkout/setup-java/upload-artifact actions to commit SHAs across all jobs. |
.github/workflows/codeql.yml |
Pins checkout/setup-java and CodeQL actions to commit SHAs for immutable CI execution. |
.github/workflows/actionlint.yml |
Pins checkout action to a commit SHA to avoid mutable tag execution. |
.github/dependabot.yml |
Adds security-update grouping for Maven and GitHub Actions ecosystems. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@coderabbitai review |
Summary
Pins every GitHub Actions reference in this repository to an immutable commit SHA and groups Dependabot security updates per ecosystem.
A version tag such as
v7is mutable and can be repointed by its upstream owner at any time, so a compromised action repository would execute inside Ares' CI without any change landing here.This closes that gap for the pipeline that gates every change to a security-enforcement library.
Linked issues
None.
1. Problem
This pull request is not driven by a defect in Ares' behaviour, so it changes neither a false negative nor a false positive. It closes a gap in the build integration layer, not in the policy layer, the generated security test or the enforcement layer.
Before this change, 16 of the 18
uses:references across.github/workflowsnamed a mutable Git tag, for exampleactions/checkout@v7andgithub/codeql-action/init@v4. Onlypullrequest-labeler.ymlandissue-labeler.ymlalready pinned to a commit SHA.A tag is a movable pointer owned by the action's publisher. Anyone who gains write access to one of those upstream repositories, or the publisher themselves, can repoint
v7at a different commit, and the next CI run here executes that commit. The observed configuration does not matter, since this holds for every job in every workflow, on every operating system and JDK.The expected behaviour is that a given commit of Ares always builds and tests with exactly the third-party code it was reviewed against, so that a CI run is reproducible and an upstream compromise cannot reach this repository without a visible diff.
Why it matters for Ares specifically: this CI is what decides whether a change to a security boundary is fit to merge. Its jobs hold a
GITHUB_TOKENand run on the runner alongside the checked-out source. An attacker controlling any action in the graph could alter test results, so a run could report green while the enforcement logic no longer rejects what it is meant to reject. The credibility of the merge gate depends on the integrity of the actions it runs.A secondary, smaller problem: Dependabot currently opens one pull request per vulnerable dependency, which spreads a single security event across several reviews.
2. Improvement from the user's perspective
Instructors ship Ares inside an exercise test repository and students submit code that runs under it. Neither group interacts with this change directly, and no policy option, failure message or runtime behaviour changes.
The indirect benefit is the trustworthiness of the merge gate that protects them: from now on, a green CI run on Ares means the enforcement logic was verified by third-party code at commits that were reviewed when they were pinned, rather than by whatever those tags point at on the day of the run. Note that release publishing does not happen in this workflow, so this pull request hardens the pipeline that gates changes, not the release path itself.
3. Improvement from the maintainer's perspective
CI runs become reproducible. Re-running an old workflow now resolves the same third-party code it originally used, so a build that changes behaviour points at a change in this repository rather than at a silent upstream tag move.
Upstream changes become reviewable. Dependabot already tracks the
github-actionsecosystem weekly, so each bump now arrives as an explicit diff of a SHA and its version comment, instead of arriving invisibly.Review load for vulnerabilities drops. Grouping security updates per ecosystem turns a batch of vulnerability fixes into one pull request instead of several. Version updates deliberately stay ungrouped, so a routine bump that breaks the build can still be reverted on its own.
Finally, this makes the repository consistent: two workflows already pinned to SHAs and the rest did not.
4. Testing manual
Prerequisites
Steps
Not reproducible from an exercise. This pull request changes only CI configuration, so a reviewer verifies it as follows:
CodeQL, which now resolvesgithub/codeql-actionfrom a commit SHA, andLint GitHub Workflows.+line of the formuses: …@<sha>carries a 40-character hexadecimal SHA followed by a semver comment, matching the convention already used inpullrequest-labeler.yml.gh api repos/actions/checkout/tags --jq '.[] | select(.commit.sha=="3d3c42e5aac5ba805825da76410c181273ba90b1") | .name', which must listv7.0.1.grep -rnE 'uses:[[:space:]]*[^[:space:]]+@(v[0-9]|main|master)' .github/must print nothing..github/dependabot.ymldeclares oneapplies-to: security-updatesgroup per ecosystem and leaves version updates ungrouped.Expected result
All five checks are green. Every action reference resolves to a commit SHA whose version comment matches the tag that upstream actually points at, and no mutable reference is left in
.github/.Negative case (what must still be rejected)
allowed_actionsis nowselected, permitting GitHub-owned actions plus the patternMaximilianAnzinger/issue-labeler@*only. A workflow that introduces any other third-party action must be refused at run start rather than executed. A reviewer can confirm the policy withgh api repos/ls1intum/Ares2/actions/permissions/selected-actions, which must reportverified_allowed: false.sha_pinning_requiredis enabled (see below), a workflow that reintroduces a mutable tag must fail to start. Until then, nothing enforces the pinning, so the reviewer's check in step 4 is what protects it.default_workflow_permissionsmust still bereadandcan_approve_pull_request_reviewsmust still befalse.Modes exercised
No mode-specific behaviour changed. The change touches no Java code and cannot alter what the enforcement layer accepts or rejects. The full
Java CI with Mavenmatrix nonetheless ran and passed on this branch.5. Test case coverage regarding this PR
No Java code changed.
Breaking changes and migration
None.
The public API under
de.tum.cit.ase.ares.api, the security policy file format and its schema, the generated security test code and the minimum JDK, Maven and Gradle versions are all untouched. Instructors need to do nothing.Accompanying repository settings
Not part of the diff, because these are repository settings rather than version-controlled files. Recorded here so the change is reviewable:
allowed_actionsset toselected, permitting GitHub-owned actions plusMaximilianAnzinger/issue-labeler@*, withverified_allowed: false.first_time_contributorstoall_external_contributors.default_workflow_permissions: readandcan_approve_pull_request_reviews: false.Follow-up after merge: the repository flag
sha_pinning_requiredis stillfalseand should be set totrueonce this lands. Enabling it beforehand would block every workflow run whoseuses:still names a mutable tag, including runs onmainand on open feature branches.Checklist
Review progress