MAMOHAMMAD ASHIF
Home›Articles›DevOps
DEVOPS · GITHUB ACTIONS · SECURITY

Secure the
delivery pipeline.

Practical controls for permissions, secrets, third-party actions, workflow trust and deployment boundaries.

By Mohammad AshifGitHub ActionsCI/CD Security10 min read
Commit→Workflow→Permissions→Build→Artifact→Deploy
✦
KEY TAKEAWAY

A CI/CD workflow can access source code, credentials and production systems. Treat every workflow permission and executable dependency as part of the software supply-chain boundary.

1. Start with Workflow Trust

Model the pipeline as a chain of trust. Every transition—from a commit to a workflow to a deployment—should have explicit permissions, protected inputs and observable outcomes.

Commit → Workflow → Permissions → Build → Artifact → Deployment

2. Minimize Workflow Permissions

Declare the smallest GitHub token permissions required by the workflow. A read-only workflow should not receive write access simply because another job needs it.

permissions:
  contents: read
Least privilege applies to CI/CD too. Review permissions at workflow and job boundaries where supported.

3. Protect Secrets

Keep deployment credentials in GitHub Secrets or an appropriate external secret-management system. Never commit credentials into workflow files, scripts or logs.

01

Minimize

Expose only the secrets a job actually needs.

02

Scope

Separate build-time and deployment-time credentials.

03

Rotate

Maintain a defined credential rotation and revocation process.

04

Observe

Prevent secrets from being emitted into logs or artifacts.

4. Govern Third-Party Actions

Third-party actions execute code inside your workflow environment. Pin or otherwise govern actions according to your organization's supply-chain policy and review what access they receive.

5. Protect the Runner

The runner is part of the execution boundary. Consider what code can execute, what credentials are available, whether the runner is shared or ephemeral, and what network access the job receives.

6. Treat Untrusted Code Carefully

Pull requests, forks and external contributions can introduce untrusted input. Do not expose sensitive credentials to untrusted execution paths simply because the workflow needs them for trusted branches.

7. Separate Deployment Trust

Use protected environments, approvals and scoped credentials where the deployment path requires stronger controls. Production deployment should be a stronger trust boundary than a normal build.

Build→Artifact→Approval→Scoped credential→Production

8. Protect Artifacts

Artifacts cross trust boundaries. Control who can publish, modify and consume them, and preserve provenance where your delivery model requires it.

9. Troubleshoot a Pipeline Security Failure

Start with the exact workflow run and identify which boundary failed: permissions, secret access, action execution, runner behavior, artifact integrity or deployment authorization.

Run→Job→Permission→Secret→Action→Deploy

10. Common CI/CD Security Mistakes

  • Broad token permissions. Workflows receive write access by default or through inherited assumptions.
  • Secrets available to every job. A compromised step gains unnecessary credentials.
  • Unreviewed actions. Third-party code runs with workflow privileges without adequate governance.
  • Production credentials in build jobs. The build boundary becomes a deployment boundary.
  • Untrusted code with secrets. Fork or pull-request execution receives sensitive credentials.
  • No artifact trust model. Build outputs are treated as trusted without provenance or controlled promotion.

11. Security Baseline

  • Default to minimum permissions.
  • Separate build and deployment credentials.
  • Govern executable third-party actions.
  • Protect production environments.
  • Keep secrets out of logs and source.
  • Monitor workflow activity.
Was this useful?Send feedback ↗