What are common mistakes with CI/CD?

Where CI/CD Mistakes Usually Start

Most CI/CD failures are not about the build tool itself, they start with weak control of the pipeline inputs and outputs. Secrets, runner permissions, approvals, and artifact integrity are the usual pressure points because each one can turn a routine deployment path into a code execution or credential exposure path. That is why secure pipeline design has to treat build and release infrastructure as production-critical, not as developer convenience.

One practical way to think about the problem is that a pipeline is both an automation system and a trust boundary. If an attacker can alter source, inject a workflow step, abuse a build token, or replace an artifact, they can often reach the same business impact as direct production access. The CI/CD Security Guide is useful here because it ties the common failure modes together, from runner isolation to branch protection and signed commits.

Another recurring mistake is assuming that “internal” pipelines are low risk. In practice, pipelines frequently bridge public code, third-party dependencies, protected secrets, and privileged deployment rights. That combination makes them attractive for supply chain abuse, especially when teams allow unreviewed promotion or depend on long-lived credentials that are reused across jobs or environments.

How Secrets, Runners, and Artifacts Get Exposed

Secret handling is one of the most common breakpoints. Secrets placed in environment variables, logs, artifact bundles, or unprotected workflow metadata can be exposed accidentally, and once a secret is available to a job it may be reachable by later steps, forked builds, or compromised dependencies. The danger is not just leakage, it is that a leaked secret can become durable access into package registries, cloud services, or deployment targets.

Build runners are the next weak point. Overprivileged runners, especially self-hosted or persistent ones, can become a pivot point if untrusted code runs on them or if workspace state survives between jobs. A compromise in the runner often means the attacker can read cached credentials, tamper with build outputs, or plant malicious changes that look like a legitimate automation result.

Artifacts and dependencies also need explicit integrity checks. If teams do not verify what is built, stored, and promoted, then a poisoned dependency or tampered artifact can move through the pipeline as though it were trusted output. The SLSA model matters here because it focuses attention on provenance, build integrity, and the evidence needed to trust what gets released.

Why Promotion Without Review Becomes an Attack Path

Unreviewed promotion is a governance flaw as much as a technical one. If code, workflow files, package metadata, or release artifacts can move to production without meaningful approval, then the pipeline becomes a bypass around normal change control. That is especially risky when the deployment path has access to signing keys, publishing tokens, or privileged infrastructure accounts.

Attackers prefer these weaknesses because they convert ordinary software delivery into a trusted execution channel. A malicious commit, a compromised dependency, or a poisoned action can travel through the same automation designed to accelerate release velocity. That is why “speed first” pipeline design often fails unless approval gates and provenance checks are built into the workflow itself, not bolted on afterward.

Several NHIMG case studies show how this plays out in practice, including secret theft, workflow poisoning, and artifact abuse across popular CI/CD ecosystems. The common lesson is that a single weak trust decision, such as trusting a third-party action, a forked build, or an unverified artifact, can cascade into broad credential exposure or release tampering.

Risk and Threat Considerations

CI/CD mistakes create concentrated exposure because one compromised pipeline can affect many repositories, environments, or downstream services at once. The failure mode is often not immediate outage, but silent trust failure: stolen secrets, altered artifacts, or unauthorized release actions that remain valid long enough to cause persistent compromise.

Failure mechanism: Weak approvals, overbroad runner permissions, and poor secret handling let adversaries move from code contribution or dependency control into build execution, credential theft, and release manipulation.

Impact: The result can be source tampering, unauthorized deployments, signing-key exposure, cloud access abuse, and long-lived compromise across multiple environments or products.

Practitioner Guidance

What to prioritise: Start with the controls that reduce blast radius, namely secret handling, runner isolation, and artifact integrity. If a build job can reach production secrets or publish directly, that path deserves immediate redesign before teams optimise any lower-risk automation.

What to verify: Confirm that every deployment path has a clear approval point, that workflow changes are reviewed like application code, and that build outputs are verifiable before promotion. If you cannot prove where an artifact came from and who approved it, you do not really control the release process.

Common mistake: Teams often secure the application and ignore the pipeline. In mature environments, the pipeline is part of the application’s attack surface, so the review standard must cover workflows, dependencies, and release credentials as carefully as the product code itself.

Practitioner takeaway: The most important judgment is to treat CI/CD as a privileged production system, because once the pipeline is trusted blindly, attackers only need one weak step to turn delivery automation into compromise automation.

Related resources from NHI Mgmt Group

• What are common mistakes with Argo CD?
• What is workload identity federation and why is it important for CI/CD security?
• How do I implement secrets scanning in a CI/CD pipeline?
• When should teams prioritise CI/CD hardening over broader secret scanning?