A release workflow should give publishing authority only to the job that needs it, after the intended source and artifact have been established. Building code and publishing a trusted release are different responsibilities.
GitHub's secure-use reference recommends least-privilege credentials and reviews several ways untrusted content can reach workflows. Use that guidance to examine the actual path from a contribution to a published artifact.
Draw the trust boundary
List the events that start the workflow and the code each job checks out. Distinguish a trusted release revision from a pull request submitted by someone who cannot publish releases.
Then list available credentials and writable resources. A job running contributor-controlled code should not gain publishing authority merely because it shares a convenient workflow file.
Pay particular attention to privileged triggers and to artifacts received from another workflow. Their presence does not make the contents trustworthy.
Grant permissions where needed
Start with the smallest default token permissions that support ordinary checks. Increase authority for a specific job only when its operations require it.
Document why each permission exists. A reviewer should be able to connect repository write access or a deployment credential to a named action.
If a workflow only produces a candidate artifact, it may not need the same authority as the later publishing job. Keep that distinction visible in the configuration.
Review executable dependencies
A third-party action runs code within the workflow's environment. Inspect its origin and behavior, then use an immutable reference such as the full commit SHA recommended by GitHub.
Pinning identifies the code; it does not replace review or maintenance. Keep an update process so a fixed version can be adopted deliberately.
Also inspect scripts downloaded during the run. Pinning the surrounding action offers limited assurance if that action immediately executes an unrelated moving dependency.
Keep event text out of generated code
Pull-request titles, branch names and other event fields are data. Avoid interpolating them directly into shell source.
Pass values through the appropriate data mechanism and quote them according to the shell being used. Test a harmless fixture containing spaces, quotes and special characters.
The expected outcome is preserved text or a validation error, not a different command.
Verify the artifact handoff
Record which revision produced the artifact and which checks ran against it. Where feasible, promote that verified artifact rather than rebuilding something different during publication.
Client Closer Kit appears in the GitHub catalogue, but its association does not disclose a CI workflow. For any downloadable product, the same question is useful: can the maintainer connect the delivered files to an approved revision?
The release artifact guide covers the user-facing half of that identity.
Finally, review logs for accidental credential exposure without copying secrets into the review report. Revoke exposed credentials through the appropriate owner rather than treating log redaction as a remedy.
A secure release process leaves a concise chain of evidence: trusted source, restricted execution, verified artifact and intentional publication. Keep that chain readable when the workflow evolves, especially when a new action or trigger is introduced.
Client Closer Kit
Stardew Valley Tracker
IcyZip