Teams should separate build, scan, and deploy stages, then minimize privilege at each step. Build images with a non-privileged builder such as kaniko, generate an SBOM before scanning, and fail the pipeline on critical findings. For deployment, use a narrowly scoped Kubernetes service account and trigger only the rollout actions the workflow genuinely needs.
Keep the pipeline split by trust boundary, not just by job order
A secure GitLab CI design treats build, scan, and deploy as different trust zones. The build stage should not need cluster-admin rights, the scan stage should only inspect artifacts, and the deploy stage should act through the smallest Kubernetes permission set that can complete the rollout. That separation limits the damage if one runner, token, or container image is compromised.
The build step is where teams most often overreach. A container builder should create images without needing the Docker daemon or broad host access, because privileged builds expand the blast radius of a malicious dependency or a poisoned build script. For provenance-aware supply-chain control, teams should also verify that each stage produces an artifact that can be traced and reviewed, not just a passing pipeline result, using guidance such as SLSA and container hardening practices from NIST SP 800-190 Container Security.
Prevent secrets, provenance gaps, and image content from becoming the attack path
Automatic image builds and deployments fail safely only when the pipeline assumes that code, dependencies, and generated images can all carry risk. The practical control point is to scan the image that will actually be deployed, not a source tree snapshot that may differ from the final artifact. Teams should also keep secrets out of build context and layer history, because leaked tokens or keys embedded during build are hard to detect and even harder to revoke once published.
That is why the build should produce an SBOM before scanning and why the pipeline should stop on critical findings instead of relying on manual review. This is especially important for container images, where vulnerable packages and embedded credentials can move from a transient build environment into long-lived registries. If you need a real-world reminder of how quickly secrets exposure can spread through CI and build outputs, NHIMG’s Reviewdog GitHub Action supply chain attack and CI/CD pipeline exploitation case study show how pipeline trust breaks when build inputs are not tightly controlled.
For artifact integrity and dependency trust, the most useful external reference is the supply-chain model in SLSA, while NIST SP 800-190 Container Security helps teams reason about image, registry, and runtime exposure as one lifecycle.
Make deployment authority narrowly scoped and observable
Deployment is the point where CI turns into production change, so the runner should not carry broad standing permissions. A Kubernetes service account for rollout should be scoped to the specific namespace and verbs required by the workflow, with no reuse for unrelated workloads. That lets teams separate “can build and sign” from “can change production,” which is the difference between a controlled automation path and a high-value lateral-movement path.
The best operational test is simple: if a pipeline token or service account were stolen, what could an attacker change, and how quickly would you detect it? Teams should be able to answer that with the exact permissions granted, the exact image digest deployed, and the exact approval or policy gate that allowed the rollout. If that evidence is unclear, the deployment side of the pipeline is still too permissive.
Practitioner takeaway: Secure CI/CD by designing for containment first, then automation, because the goal is not to make every step privileged, but to ensure each step can only perform the minimum action required and nothing more.
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 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | CI deploy and build permissions depend on least-privilege access control. |
| 8 — Audit Log Management | Pipeline and rollout activity must be observable for abuse and failure detection. | |
| 16 — Application Software Security | Container images and CI artifacts need scanning and hardening before release. | |
| Recommendation — Restrict pipeline and service-account permissions to the minimum actions needed. Log build, scan, and deployment actions with enough detail to trace each release. Scan build outputs and block promotion on critical image and dependency findings. | ||
| NIST CSF 2.0 | PR.AC-4 — Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties | The pipeline should separate build and deploy authority to limit blast radius. |
| PR.DS-6 — Data is checked for integrity | Image provenance and SBOM-driven checks support artifact integrity before deployment. | |
| DE.CM-8 — Vulnerabilities are monitored and identified | Automatic image scanning is a vulnerability-monitoring control for CI-produced artifacts. | |
| Recommendation — Separate build and deployment permissions so no pipeline step has unnecessary authority. Verify artifact integrity and provenance before promoting an image to production. Continuously scan built images and block release on critical vulnerabilities. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Scoped service-account use and trust boundaries in deployment rely on strong digital identity governance. |
| Recommendation — Use well-governed machine identities for deployment actions and revoke unnecessary access quickly. | ||
| NIST Zero Trust (SP 800-207) | SC-4 — Separation of Duties | Build, scan, and deploy should be separated into distinct trust functions. |
| AC-6 — Least Privilege | Narrow Kubernetes and CI permissions directly align to least-privilege deployment. | |
| Recommendation — Split pipeline duties so compromise of one stage does not grant end-to-end control. Grant each pipeline component only the privileges required for its specific task. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Least Privilege and Permission Scoping | Pipeline tokens and service accounts are non-human identities that should be tightly scoped. |
| Recommendation — Scope CI and deployment identities to the smallest viable set of permissions. | ||
Related resources from NHI Mgmt Group
- How should security teams secure GitLab access from CI/CD pipelines?
- How should teams secure build pipelines that produce embedded Linux images?
- How should teams secure CI/CD pipelines against identity-based attacks?
- How should security teams respond when a trusted-publisher npm supply chain compromise is detected in CI or build pipelines?
