Skip to main content
GitHub Actions is a powerful CI/CD platform, but without proper safeguards, workflows can introduce risks to your code, infrastructure, and sensitive data. This guide walks through four key areas of hardening your GitHub Actions security:
  • Secrets Management
  • OpenID Connect (OIDC)
  • Mitigating Script Injection
  • Third-Party Actions

1. Secrets Management

Storing credentials, tokens, and other sensitive information directly in workflows is a critical security risk. GitHub provides a robust secrets management system:
  • Encrypted storage
    Secrets are encrypted client-side with Libsodium sealed boxes before being sent to GitHub.
  • Scoped access
    You can define secrets at the organization, repository, or environment level.
  • Masked output
    Any secret that appears in logs is automatically redacted.
Use the GitHub UI or REST API to add secrets. In your workflow, reference them as follows:
Regularly rotate your secrets and remove any unused credentials to limit blast radius.

2. OpenID Connect (OIDC)

Instead of long-lived cloud credentials, leverage short-lived tokens via OIDC. This eliminates static secrets and reduces credential exposure.
  1. Trust GitHub’s issuer
    Configure your cloud provider to trust https://token.actions.githubusercontent.com as an OIDC identity provider.
  2. Grant OIDC permissions
    In your workflow, request the id-token permission:
  3. Configure credentials with an action
    For AWS, you can use the official AWS OIDC action:
Short-lived tokens automatically expire, minimizing the risk of credential theft or misuse.

3. Mitigating Script Injection

When workflows process external or user-supplied data, attackers may inject malicious commands. Protect your runners by following these best practices:
  • Never concatenate untrusted input into shell commands.
  • Use action inputs or parameterized APIs instead of manually building commands.
  • Validate and sanitize all external data.
  • Prefer official or well-audited actions for complex processing.
Running unchecked user input in a shell step can expose secrets, corrupt workflows, or allow remote code execution.

4. Third-Party Actions

Community actions speed up development but can also introduce vulnerabilities or excessive permissions. Evaluate and manage third-party risks with this matrix: Best practices:
  • Pin actions to a commit SHA instead of a floating tag.
  • Limit the permissions scope to the bare minimum (principle of least privilege).
  • Periodically review third-party code for updates or security advisories.
The image is an infographic about GitHub Actions security hardening, highlighting four areas: Secrets, OpenID Connect, Script Injection, and Third-Party Actions, with specific security measures for each. It also suggests using own, verified, and public actions in a specific order.

Watch Video