CI pipelines should use the minimum permissions required because third-party actions can otherwise read or change more than intended. Even trusted actions can be compromised, which creates supply-chain risk after checkout. Pinning actions to commit hashes reduces the chance that a tag silently points to different code later, improving reproducibility and limiting attack surface.
Why permissions and pinning matter together in CI
When a pipeline invokes third-party actions, the pipeline is extending trust beyond your own repository. Explicit permissions reduce what those actions can do if they are legitimate but overly broad, while pinning prevents a later upstream change from altering behaviour without review. Together, they constrain both accidental overreach and supply-chain compromise.
The key security issue is that CI systems often run with access to source code, build artifacts, secrets, deployment targets, and repository write permissions. If a third-party action inherits more privilege than it needs, any bug or malicious payload in that action can use those privileges immediately. Pinning to a commit hash narrows the chance that a trusted name later resolves to different code.
- Limit token scope to the smallest set of repository and workflow permissions required.
- Pin reusable actions to immutable commit hashes, not mutable tags.
- Review privilege changes as part of workflow change control, not only application release control.
What goes wrong when workflows trust too much
Third-party actions are a common attack path because they are convenient, widely reused, and often placed into privileged build jobs. A compromised action can read secrets, alter build outputs, modify release artifacts, or inject backdoors into packages and deployments. The danger is not limited to obviously untrusted code, because even a reputable action can become a delivery mechanism after its upstream source changes.
Mutable references such as version tags create a hidden dependency on the publisher’s future integrity. If a tag is moved, an attacker who gains maintainers’ access, compromises a release process, or tampers with distribution can make the workflow fetch new code under an old label. That makes the pipeline less reproducible and makes incident review harder because yesterday’s build may not match today’s checkout of the same tag.
Failure mechanism: Broad workflow permissions and mutable action references combine to let a third-party component execute with more authority than the task requires, or to receive different code later without the pipeline owner noticing.
Impact: The result can be secret disclosure, artifact tampering, unauthorized repository changes, and downstream supply-chain compromise that propagates beyond the CI system itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | CI permissions and pinned actions protect the secrets third-party actions can reach. |
| NHI-03 — Third-Party and Supply-Chain Risk | The question is centered on third-party action compromise and supply-chain trust drift. | |
| Recommendation — Restrict workflow tokens and rotate exposed secrets when third-party actions are used. Pin external actions and verify publishers before allowing them into privileged workflows. | ||
| CIS Controls v8 | 6 — Access Control Management | Least-privilege permissions are the core control for CI workflow access. |
| 16 — Application Software Security | Pinned actions support software integrity and reduce unreviewed code changes in pipelines. | |
| Recommendation — Apply least privilege to CI tokens and workflow permissions. Verify the integrity of build-time dependencies and lock external components to approved versions. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Explicit permissions are an access-control decision for build automation. |
| PR.DS — Data Security | Third-party actions can expose secrets and build data if over-permissioned. | |
| PR.IP — Information Protection Processes and Procedures | Pinning actions is a process control that improves reproducibility and change integrity. | |
| Recommendation — Scope CI access so each workflow can perform only the actions it truly needs. Protect secrets and build data from unnecessary exposure to third-party workflow components. Require immutable references for external actions in controlled build and release processes. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | A compromised action or moved tag is a classic supply-chain compromise path. |
| T1528 — Steal Application Access Token | Over-permissioned CI jobs often expose tokens that third-party actions can steal or misuse. | |
| Recommendation — Hunt for compromised dependencies and validate the provenance of pipeline components. Reduce token exposure in workflows and monitor for access-token abuse. | ||
| NIST SP 800-63 | IAL/AAL/Authenticator management — Digital Identity Assurance and Authenticator Lifecycle | Credential exposure in CI is an authenticator lifecycle and trust problem when pipelines access sensitive systems. |
| Recommendation — Treat pipeline credentials as authenticators that require strict lifecycle control and revocation. | ||
Practitioner Guidance
What to verify: Treat every third-party action as a privileged dependency. Verify which tokens it can read, whether it needs write access, and whether it touches release steps, artifact signing, or deployment credentials. If the action does not need a permission, remove it rather than assuming a future review will catch misuse.
What good looks like: The workflow is explicit about permissions, each external action is pinned to a commit hash, and the team can explain why that exact version is trusted. For higher-risk pipelines, review whether the action’s maintainer, release process, and change history are themselves acceptable dependencies.
Practitioner takeaway: The real control objective is not just preventing bad code from running, but ensuring that any code allowed into the pipeline has tightly bounded authority and cannot drift silently after approval.
Related resources from NHI Mgmt Group
- What happens when CI/CD pipelines rely on untrusted third-party tools, actions, or libraries?
- How should teams handle third-party GitHub Actions in production pipelines?
- How should security teams secure Python applications that rely on third-party packages and CI/CD pipelines?
- Who is accountable for securing CI/CD workflows that depend on third-party actions?
