A GitHub Actions Security Checklist for Your First Pipeline

A pipeline runs code with access to repositories, artifacts, and sometimes deployment credentials. Treat that access as part of your design. A small workflow that builds and tests an application is a good place to practise reviewing permissions before adding production deployment.

Use this checklist with GitHub’s secure-use reference. It is a learning review, not a complete security assessment of every repository or deployment environment.

Name what each job needs

Read each job and identify the resources it must access. A test job may only need to read repository contents. A publishing job can need different permissions. Use the workflow permissions reference to set permissions deliberately at the appropriate workflow or job scope, then confirm that the workflow still performs its intended task.

Avoid handing every job a broad credential simply because one deployment step needs it. A failed job should prompt an investigation of the specific missing permission rather than an immediate switch to administrator access.

Review the actions you depend on

Third-party actions execute code in your workflow. Read the repository, understand the action’s purpose, and inspect what permissions and inputs it requires. GitHub recommends pinning actions to a full-length commit SHA to identify an immutable version.

Pinning also creates maintenance work. Record which release the SHA corresponds to and plan how updates will be reviewed. A stable reference does not make an action trustworthy on its own.

Keep untrusted text out of shell code

Pull-request titles, branch names, and issue text can contain attacker-controlled input. Directly inserting that text into a shell script can change how the script is interpreted.

Prefer a documented action or pass values through an environment variable and handle them as data with appropriate quoting. Read the exact example in GitHub’s secure-use reference before adapting it. Do not assume that text is harmless because it appears inside a repository you own.

Separate testing from privileged deployment

Use the workflow events reference to map the trigger for every workflow. A pull request from an outside contributor should not automatically gain the same privileges as a reviewed production release. Pay particular attention to workflows that combine privileged events with checkout or execution of untrusted code.

Use a deployment process with explicit environment rules where appropriate. Verify the rules that apply to your repository and plan. Keep the conditions for production release understandable to another reviewer.

Reduce long-lived credentials

Where the cloud provider and workflow support it, investigate OpenID Connect federation so a job can obtain appropriately scoped temporary credentials. This needs correct trust conditions; allowing any repository or branch would defeat the intended restriction.

If a stored secret is necessary, scope it, rotate it through your established process, and avoid printing it. Masking in logs is helpful but should not be treated as proof that all sensitive values are protected in every representation.

Make the review visible in your project

Add a short section to the README listing the workflow triggers, job permissions, external actions, credentials, and deployment conditions. Explain what a contributor can trigger and what requires review.

Revisit this list when adding a publishing step, a new runner, or an external action. Security review is easier when the pipeline stays small and the reason for each permission is written down. Continue with the CI/CD glossary entry and the DevOps tools guide.