CI/CD pipelines are high-value targets because they can execute code, reach secrets, and modify release artefacts. Least privilege limits what automation can do if a token is abused, while action and image pinning reduce the chance that an upstream change silently introduces risk. Together, these controls shrink the blast radius and make pipeline behaviour more predictable.
Why these controls matter in pipeline security
CI/CD pipelines are not just build utilities, they are trusted execution paths. They often authenticate to source control, artifact stores, cloud platforms, and deployment targets, so any overly broad permission or unpinned dependency can turn a routine automation step into a supply-chain event. least privilege keeps that trust boundary narrow, while action and image pinning make the pipeline’s behaviour auditable and repeatable.
That predictability matters because pipelines are designed to move fast. If a maintainer, third-party action, or container image changes unexpectedly, the pipeline may inherit new code or permissions without an obvious review step. A tightly scoped token can still be dangerous, but it reduces what a compromised job can reach; pinning reduces what the job can silently become.
Pipeline controls also need to be understood as a whole, not as separate hardening tricks. Least privilege limits the authority of the runner, secret, or service account; pinning limits the integrity risk introduced by upstream content. When both are present, the organisation gets better containment if something is abused and better assurance that the pipeline is executing the intended version of each step.
Where failures usually appear
The common failure mode is convenience-first configuration. Teams grant broad write access to repositories, package registries, deployment systems, and cloud resources because it is easier than scoping each job to one task. They also reference mutable tags instead of fixed versions, which means a later upstream change can alter behaviour after the workflow was approved. In practice, that combination creates both privilege creep and dependency drift.
Another weak point is secret handling inside the pipeline itself. A job that can read long-lived credentials can usually reuse them outside the build window, so the blast radius is not limited to the single execution. Pinning helps preserve integrity, but it does not replace review of what the action or image can do once it runs. The right control set needs to constrain both who can act and what exact code is trusted to act.
For teams looking for a broader identity and access lens on this problem, the control logic is the same one that underpins least-privilege governance across non-human identities, including the way service accounts, API keys, and automation tokens are scoped and rotated in practice. NHI Mgmt Group’s Ultimate Guide to NHIs and key challenges and risks are useful reference points for that governance layer, while the GitHub Action supply-chain attack example shows how quickly pipeline secrets can be exposed when trust is too broad.
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 NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 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/CD pipelines rely on automation secrets and tokens that need tight scoping and rotation. |
| NHI-02 — Least Privilege and Access Control | Least privilege directly limits the blast radius of abused pipeline identities. | |
| NHI-06 — Supply Chain Integrity | Action and image pinning reduce the risk of silent upstream dependency changes. | |
| Recommendation — Scope pipeline secrets to the minimum access needed and rotate them regularly. Restrict pipeline identities to only the permissions required for each job. Pin reusable actions and container images to trusted immutable references. | ||
| NIST Zero Trust (SP 800-207) | DP-3 — Least-Privilege Access | Zero Trust requires narrowly scoped access for automation paths that reach code and deployment systems. |
| Recommendation — Enforce least-privilege access for every CI/CD identity and workflow. | ||
| CIS Controls v8 | 6.3 — Manage Default Accounts and Access Grants | CI/CD permissions should be reviewed and removed when they exceed the job's needs. |
| 16.12 — Verify Software Supply Chain Integrity | Pinned actions and images support integrity checks for software delivered through the pipeline. | |
| Recommendation — Review and revoke unnecessary pipeline access grants on a regular basis. Verify that build and release dependencies are pinned to approved versions. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Pipeline secrets are attractive targets because they can be abused after theft. |
| T1195 — Supply Chain Compromise | Mutable actions and images can introduce malicious or altered code into the pipeline. | |
| Recommendation — Hunt for and reduce exposed pipeline credentials across repositories and build systems. Map third-party build dependencies to supply-chain compromise risk and verify provenance. | ||
| NIST CSF 2.0 | PR.AC — Access Control | CI/CD least privilege is an access-control problem for automation identities and build systems. |
| PR.DS — Data Security | Pipelines often handle secrets and release artefacts that need integrity and confidentiality protection. | |
| Recommendation — Limit pipeline access to the minimum set of resources and actions needed. Protect pipeline secrets and artefacts from unauthorized exposure or alteration. | ||
Practitioner Guidance
What to prioritise: Start with the credentials and permissions that can reach production systems, release artefacts, or signing material. If a workflow can deploy, publish, or read secrets, treat that path as materially more important than cosmetic hardening elsewhere in the pipeline.
What to verify: Confirm that workflow steps reference fixed, reviewable versions and that runners only have the minimal repository, registry, and cloud permissions required for the job. If a control depends on a moving tag or a broadly scoped token, the control is weaker than it appears.
Common mistake: Teams often pin actions but leave the runner over-privileged, or they scope permissions well but continue to consume mutable images. The control only becomes robust when integrity and authority are both constrained.
Practitioner takeaway: The objective is not to make CI/CD harmless, it is to make it fail in a bounded and explainable way, with no hidden permission growth and no silent dependency drift.
Related resources from NHI Mgmt Group
- How should security teams implement least privilege access in CI/CD pipelines without slowing delivery teams down?
- How should organisations enforce CRA-ready controls in CI/CD pipelines?
- How should teams implement code security controls in CI/CD pipelines?
- How should teams implement SLSA controls in CI/CD pipelines?
