Feature: Packaging check should detect step-security/goreleaser-action (maintained fork of goreleaser/goreleaser-action)

[arcaven]

Is your feature request related to a problem? Please describe.
The Packaging check detects Go publishing workflows by matching uses: goreleaser/goreleaser-action (checks/fileparser/github_workflow.go, IsPackagingWorkflow). StepSecurity maintains an actively-synced fork of that action, step-security/goreleaser-action, as part of its Secure-Workflows / maintained-actions program, and repositories that adopt it publish releases through exactly the same GoReleaser workflow. Those repositories currently score -1 ("packaging workflow not detected") on the Packaging check even though they genuinely publish via GoReleaser — the harder they lean into supply-chain hardening (StepSecurity mirrors), the less packaging credit Scorecard gives them.

Observed on our fleet (e.g. github.com/ArcavenAE/marvel, github.com/ArcavenAE/sideshow, github.com/ArcavenAE/ThreeDoors): each publishes GitHub releases from release.yml via step-security/goreleaser-action@<sha>, and Packaging reports "packaging workflow not detected".

Describe the solution you'd like
Add a job matcher for step-security/goreleaser-action alongside the existing goreleaser/goreleaser-action matcher in IsPackagingWorkflow, so both spellings of the same publishing workflow are recognized. I have a PR ready to offer implementing this (one additional matcher + unit test coverage).

Describe alternatives you've considered

• A generic alias/mirror mechanism mapping maintained forks to their upstream actions (e.g. all step-security/* mirrors). More complete, but a much bigger design decision — the single-action addition is the minimal, precedent-consistent step (the matcher list already carries renamed spellings of the same tool, e.g. imjasonh/setup-ko / ko-build/setup-ko).
• Repositories switching back to goreleaser/goreleaser-action purely to regain detection — works, but penalizing use of a hardened mirror seems backwards.

Additional context
Happy to submit the PR — it is additive detection only; no existing scores decrease. Flagging per CONTRIBUTING.md's "Changing score results" guidance since detected repos would move from -1 (excluded) to a real Packaging score.

[arcaven]

One more data point on why this matters to Scorecard specifically, found while preparing the PR: Scorecard's own remediation guidance for the Token-Permissions and Pinned-Dependencies checks directs users to StepSecurity's secureworkflow tool (docs/checks.md), and that tool's maintained-actions feature is precisely how workflows end up on step-security/goreleaser-action. So the false negative isn't incidental — following Scorecard's own hardening recommendations can cost a project its Packaging detection. PR: #5132.