A CI/CD pipeline is not merely a delivery mechanism. It is a privileged system that reads source code, accesses cloud environments, retrieves credentials, produces artifacts, and can deploy directly to production. That concentration of access makes the top risks in CI/CD pipelines consequential: one weak workflow, token, or runner can turn a routine code change into a software supply chain incident.
Fast delivery and strong controls are not opposing goals. The objective is to make the secure path the default path, so engineering teams can ship without relying on individual caution at every handoff.
Why CI/CD Pipelines Are High-Value Targets
A modern pipeline often has broader permissions than the developer who triggered it. It may use service identities that can publish packages, assume cloud roles, update infrastructure, sign releases, or access deployment secrets. Attackers understand this. Compromising a build pipeline can provide a clean route to malicious artifacts or production infrastructure without exploiting the application itself.
The risk grows with convenience features. Third-party actions, reusable templates, shared runners, automated dependency updates, and chat-based deployment commands all reduce operational friction. They also expand the trust boundary. Security teams need to evaluate the complete path from pull request to deployed workload, not just the code repository.
The Top Risks in CI/CD Pipelines
Exposed secrets in code, logs, and configuration
Secrets frequently enter pipelines through environment variables, repository settings, configuration files, build arguments, or copied shell commands. A token can be exposed by a verbose build log, included in a container layer, committed to a test fixture, or passed to an untrusted action. Redaction helps, but it is not a primary control. It can fail when a secret is transformed, truncated, encoded, or printed in an unexpected format.
Treat every pipeline secret as a production credential with a defined owner, scope, expiration policy, and rotation process. Avoid long-lived personal access tokens for automation. Use workload identities or short-lived credentials wherever the platform supports them, and ensure deployment jobs receive only the secrets required for that environment.
Secret collection is another overlooked entry point. Teams still receive API keys and administrative credentials through email, chat, and ticket comments, then manually move them into CI settings. Securitae provides a controlled alternative for collecting sensitive values through encrypted secure links, reducing the chance that credentials are scattered across communication systems before they reach the appropriate vault or pipeline configuration.
Overprivileged pipeline identities
Many pipeline breaches are authorization failures rather than authentication failures. A valid token with broad cloud permissions is still dangerous when a pull request, compromised dependency, or poorly reviewed workflow can cause it to run arbitrary commands.
Separate build, test, publish, and deploy identities. A test job should not be able to deploy production infrastructure. A documentation workflow should not have package publishing rights. Production deployments should use narrowly scoped identities with explicit approval gates, protected branches or tags, and environment-level authorization.
This requires some operational discipline. Fine-grained permissions create more policy objects to manage, and overly restrictive controls can slow emergency fixes. The answer is not a single all-powerful token. It is a documented break-glass process with logging, time limits, and post-incident review.
Untrusted pull requests and arbitrary code execution
CI systems execute code by design. The distinction that matters is whether the code is trusted at the moment privileged credentials become available. External pull requests, forked repositories, user-controlled build parameters, and pull request metadata can all become attack paths when workflows are configured carelessly.
Do not expose secrets to workflows triggered by untrusted contributions. Be especially careful with event types that run in the context of the base repository while checking out pull request code. Validate inputs used in shell commands, quote variables consistently, and avoid dynamically constructing commands from branch names, commit messages, issue titles, or user-supplied parameters.
Reviewers should also inspect workflow-file changes with the same scrutiny applied to infrastructure-as-code changes. A one-line modification can redirect an artifact upload, print environment variables, or change which identity a job assumes.
Compromised third-party actions and build dependencies
A pipeline may rely on marketplace actions, container images, language packages, plugins, and build tools maintained outside the organization. Every dependency introduces code that can execute within a trusted delivery path. Tag-based references such as `@v3` are convenient, but they permit upstream changes without a corresponding change in your repository.
Pin third-party actions and critical build images to immutable commit hashes or digests. Maintain an allowlist for approved actions, and periodically review whether each one still needs access to secrets, repository tokens, or network resources. Prefer small, well-understood components over broad automation packages that receive extensive permissions.
Dependency scanning remains useful, but it does not answer the central pipeline question: what code is permitted to execute with privileged access? Inventory and provenance controls are needed alongside vulnerability scanning.
Weak artifact integrity and provenance
If teams cannot prove which source, dependencies, build environment, and workflow generated an artifact, they have limited ability to detect tampering. This matters for application binaries, containers, infrastructure modules, and internal packages alike.
Build artifacts once, store them in a controlled registry, and promote the exact same artifact across environments. Rebuilding separately for staging and production creates room for drift and makes investigation harder. Generate signed attestations that bind artifacts to source revisions and build identities, then enforce verification before deployment where feasible.
The practical level of rigor depends on the system. A low-risk internal tool may begin with immutable artifact tags and restricted registry writes. Customer-facing SaaS platforms handling sensitive data should move toward signed artifacts, provenance attestations, and admission controls that reject unverified workloads.
Shared or poorly isolated runners
Runners are execution environments, and shared runners can create cross-job exposure when isolation is weak. An attacker who gains persistence on a self-hosted runner may capture credentials, alter builds, or inspect workspace data from unrelated jobs. Even ephemeral runners are not automatically safe if their host configuration, network access, or image supply chain is poorly controlled.
Use ephemeral runners for sensitive workloads whenever possible. Start each job from a known image, destroy it afterward, and restrict network paths to only required services. Separate runners by trust level: public contribution jobs, internal testing, release builds, and production deployments should not share the same execution pool.
Self-hosted runners can be appropriate when builds need private network access or specialized hardware. They demand stronger operational controls, including hardened base images, patching, endpoint monitoring, restricted administrative access, and audit logs that connect runner activity to specific workflow runs.
Pipeline drift and bypass paths
Security controls lose value when teams can bypass them through alternate deployment paths. A protected production workflow does not help if an engineer can deploy directly with a broad cloud credential, overwrite an artifact tag, or modify a release branch without required review.
Map the real release process, including emergency changes, infrastructure updates, database migrations, feature-flag changes, and manual cloud-console actions. Then align repository protections, cloud IAM, registry permissions, and change-management expectations with that process. The goal is not to eliminate every manual action. It is to make exceptions visible, constrained, and auditable.
Building Controls Without Breaking Delivery
Start with the identities and secrets that can change production. For each one, identify where it is stored, which workflow can request it, what code can run before it is issued, and what permissions it grants. This exercise often reveals unnecessary standing access before a new security tool is deployed.
Next, establish a small set of non-negotiable release controls: protected workflow definitions, least-privilege job tokens, isolated runners, immutable artifacts, and production approvals tied to verified source and artifacts. Apply stronger requirements to high-impact paths first. A payment service and a preview environment should not carry identical control overhead.
Finally, treat pipeline telemetry as part of incident readiness. Retain workflow logs, identity-assumption events, artifact publication records, and deployment audit trails. During an investigation, the question is rarely just whether an alert fired. It is whether the organization can reconstruct exactly what was built, who authorized it, and what reached production.
A secure CI/CD program earns trust when it makes the release path predictable. When credentials are short-lived, build inputs are controlled, and artifacts are verifiable, teams can move quickly with fewer hidden assumptions.