Amey-Thakur Actions security
CI runs with credentials and executes code from the repository, which makes it an attractive target. The dangerous configurations are workflows triggered by outside contributions that also have access to secrets.
Method
- Never expose secrets to fork pull requests. The trigger that grants a token to untrusted code is the central risk, and any workflow needing secrets should not run on unreviewed forks.
- Treat pull request content as untrusted input. Titles, branch names, and body text interpolated into shell commands are an injection path, so they belong in environment variables rather than inline (see input-validation).
- Pin third-party actions to a full commit hash. Tags are mutable, and an action you trusted can change under you (see supply-chain-security).
- Scope the workflow token minimally. Read-only by default with write permissions granted per job that needs them.
- Keep secrets out of logs. Masking helps and is not complete, so avoid echoing anything derived from a secret (see secrets-management).
- Require approval for first-time contributors. Manual approval before workflows run on a new contributor's pull request is a cheap and effective control.
- Review workflow changes as security changes. A pull request editing a workflow can exfiltrate secrets, and it deserves the same scrutiny as a change to authentication code.
Boundaries
These controls reduce exposure; a compromised maintainer account bypasses all of them. Self-hosted runners have a substantially larger attack surface and should not run untrusted code. Third-party actions are dependencies with the same trust implications as any other.