[arcaven]

Why this matters: the Packaging check recognizes GoReleaser publishing only under the literal spelling goreleaser/goreleaser-action. Projects that publish through step-security/goreleaser-action — a hardened, actively-synced fork of the same action (StepSecurity, the harden-runner vendor, maintains such forks with pinned dependencies and release provenance) — score -1, "packaging workflow not detected."

The result is that Scorecard unintentionally discourages a security-hardening choice: switch to the hardened fork, lose your Packaging credit. Supporting detail: Scorecard's own remediation docs point users at StepSecurity's secureworkflow tooling, so this is a path Scorecard users actually take.

The fix is one additive matcher. No existing score can decrease; affected repos move from -1 (check excluded) to a real score.

What kind of change does this PR introduce?

Feature — a new job matcher in the Packaging check.

• PR title follows the guidelines defined in our pull request documentation

What is the current behavior?

IsPackagingWorkflow matches Go publishing workflows only via goreleaser/goreleaser-action. Repositories using the step-security/goreleaser-action fork score -1 despite publishing releases through the identical GoReleaser flow. Observed on real repositories (e.g. github.com/ArcavenAE/marvel, github.com/ArcavenAE/sideshow).

What is the new behavior (if this is a feature change)?

A second matcher recognizes step-security/goreleaser-action with the same LogText as the upstream action, following the existing precedent of listing renamed/mirrored spellings of one tool (imjasonh/setup-ko / ko-build/setup-ko). Detection is additive only.

• Tests for the changes have been added (for bug fixes/features) — new testdata workflow github-workflow-packaging-go-step-security.yaml + a TestIsPackagingWorkflow case.

Which issue(s) this PR fixes

Fixes #5131

Special notes for your reviewer

Per CONTRIBUTING.md's "Changing score results" guidance, the motivating discussion is in #5131. If you'd rather solve this generally (an alias table mapping maintained forks to upstream actions — StepSecurity maintains forks of many popular actions, so this likely recurs), happy to rework in that direction; this PR is the minimal precedent-consistent step.

Does this PR introduce a user-facing change?

The Packaging check now detects Go publishing workflows that use step-security/goreleaser-action, the StepSecurity-maintained fork of goreleaser/goreleaser-action.

[github-actions]

This pull request has been marked stale because it has been open for 10 days with no activity

[arcaven]

@spencerschrock @AdamKorcz this looked like an easy win, I know it's gone stall. As I'm new here, is there something you'd like to see, additional testing (CI jobs are blocked in new contributor) that would help?

[arcaven]

@spencerschrock — does this fit the project’s spirit, in the same vein as the Packaging-check work around #4673, #4684, and #2964, or would you recommend approaching it differently?

I noticed Scorecard’s own remediation guidance points users toward StepSecurity’s secureworkflow, and StepSecurity maintains the GoReleaser fork addressed by #5132. I hoped recognizing that maintained spelling—and fixing the equivalent setup-ko matcher issue in #5134—would be a welcome contribution, in addition to improving Scorecard assessments for projects we consume and publish.

Happy to reshape these if they aren’t the right fit.

[arcaven]

Both this and #5134 are rebuilt on current main and green locally (go build ./checks/..., go test ./checks/...), so neither is stale as a branch. I would rather not keep pinging, so this is the last note from me unless something changes.

One thing that is new since I last wrote: on the sibling #5134, @daichunghy confirmed on 2026-08-22 that the ko matcher problem still reproduces on current main and walked through JobMatcher.matches requiring every listed step. That is independent of me, and it is the same Packaging-check surface both PRs touch.

The honest position is that I cannot tell whether these are waiting on review bandwidth or on a decision that recognizing a hardened fork is out of scope for Packaging. Either answer is useful and closes it out. If it is the second, say the word and I will close both myself rather than leave them sitting in your queue.

If it is the first and CI is the obstacle, the workflows are still blocked for me as a new contributor, so a maintainer run is the only way to get a signal.

[github-actions]

This pull request has been marked stale because it has been open for 10 days with no activity

[arcaven]

@spencerschrock, I would still like to land this, and its checks are green. Could you review it when you have a moment, or point me to someone better placed to?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.32%. Comparing base (353ed60) to head (52e075f).
⚠️ Report is 422 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #5132       +/-   ##
===========================================
+ Coverage   66.80%   77.32%   +10.52%     
===========================================
  Files         230      255       +25     
  Lines       16602    14468     -2134     
===========================================
+ Hits        11091    11188       +97     
+ Misses       4808     3279     -1529     
+ Partials      703        1      -702     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.