Skip to content

Clear the open DevHub findings - #44

Merged
marissalk-glia merged 4 commits into
masterfrom
pin-github-actions
Sep 10, 2026
Merged

Clear the open DevHub findings#44
marissalk-glia merged 4 commits into
masterfrom
pin-github-actions

Conversation

@marissalk-glia

Copy link
Copy Markdown
Contributor

DevHub reports five zizmor findings for this repo, three high and two medium. This clears all five.

A version tag is mutable. Whoever can push to one of these action repos
can move the reference to different code, and our next workflow run
picks it up. DevHub flags this as a high-severity
unpinned_github_actions violation.

ruby/setup-ruby@v1 was the weaker of the two. On that repo v1 is a
branch rather than a tag, so it is expected to move and nobody would
read a move as suspicious. Its head is v1.321.0, which is what the pin
records, so the action does not change.

Checkout goes from v3.7.0 to v7.0.1. Nothing here depends on the
credential handling that changed in v6: no git commands run after
checkout, and submodules: true is a no-op because the repo has no
.gitmodules.

The cost is that setup-ruby no longer tracks its own updates, so a
newer Ruby in the matrix may need a bump here too.
The workflow has no permissions: block, so the job runs with the
repository default token scope. zizmor flags this as
excessive-permissions (high), and DevHub reports it.

Every step only reads the repo: checkout, setup-ruby, then
bundle exec rake. Nothing writes back.
Checkout leaves the job token in the workspace git config, so zizmor
raises an artipacked finding on each workflow and DevHub reports both.
Neither job uses those credentials.

The Ruby build only reads. submodules: true is a no-op, since there is
no .gitmodules and no gitlink entry in the index. bundler-cache: true
makes setup-ruby run bundle install, and the Gemfile has no git sources.
The gemspec shells out to git ls-files, which is a local read.

The gitleaks scan only execs the gitleaks binary against the local
clone. It reaches the GitHub API through the GITHUB_TOKEN we pass in
env, not through git.
The scan pinned v6.0.0, one major behind, so DevHub showed it as stale.
Both workflows now sit on the same pin.

v7's one breaking change does not reach us. It blocks checking out a
fork PR head for pull_request_target and workflow_run, and neither
workflow uses those triggers.

v6.0.0 was also a bad place to sit. GitHub backported that same fork PR
block to v6.1.0, so v6.0.0 is the last v6 without the safer default.
@marissalk-glia
marissalk-glia marked this pull request as ready for review September 10, 2026 09:56
@marissalk-glia
marissalk-glia requested a review from a team as a code owner September 10, 2026 09:56
@marissalk-glia
marissalk-glia merged commit 52ba8c2 into master Sep 10, 2026
5 checks passed
@marissalk-glia
marissalk-glia deleted the pin-github-actions branch September 10, 2026 10:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants