CI/CD Security: How to Protect Your Pipeline from Code to Deployment

What Is CI/CD Security?

CI/CD security refers to embedding security controls throughout the continuous integration and continuous delivery (CI/CD) pipeline, from code commit to production deployment. It covers access controls on repositories, secrets management in build environments, dependency integrity checks, artifact validation, and runtime monitoring of deployed workloads.

This discipline sits within the broader DevSecOps operational model. CI/CD security, when treated as a shared team responsibility rather than a gate that blocks releases, is enabled by the shift left from SecOps to DevSecOps. Security controls are embedded in CI/CD workflows, so they operate at machine speed and do not require manual review at every step.

Why CI/CD Pipelines Are a High-Value Target

CI/CD pipelines sit atop source code, secrets, cloud credentials, and production deployment targets. If a single dependency or configuration gets compromised, malicious code can propagate across every environment that the pipeline deploys to. 

A compromised pipeline grants more access than most individual engineers hold. We saw this play out in March 2025. The tj-actions/changed-files GitHub Action was compromised, exposing CI/CD secrets across more than 23,000 repositories. A component that thousands of teams trusted became a credential-theft vector overnight.

Direct access to source code, secrets, and production environments

Build runners have to routinely deal with cloud provider credentials, database connection strings, API tokens, and container registry passwords. In many cases, these secrets are saved as environment variables or hardcoded into configuration files, exposing them to any processes running in the build environment.

Compromising a single runner can allow threat actors to exfiltrate credentials that grant them direct access to production databases, cloud infrastructure, and container registries across the organization.

How automation amplifies risk

Automation is the pipeline’s strength and its vulnerability. A malicious commit that gets through automated checks propagates to build, test, and deploy without human inspection. Since the CI/CD process trusts the pipeline output, poisoned artifacts can reach staging or production environments within minutes.

What attackers can do with a compromised pipeline?

Once attackers gain access to the pipeline, they can embed backdoors into build artifacts, steal credentials stored and passed as environment variables to downstream jobs, spin up cryptominers on shared build infrastructure, and spread malicious code down the supply chain via malicious commits. 

A supply chain attack occurred when attackers manipulated the build system at SolarWinds, inserting a backdoor into software updates sent to 18,000 organizations.

The OWASP Top 10 CI/CD Security Risks

The OWASP Top 10 CI/CD Security Risks framework provides the industry-standard taxonomy for pipeline threats. Each risk below maps to a specific control gap that attackers exploit in production CI/CD environments.

1. CICD-SEC-1: Insufficient flow control mechanisms

This risk arises when pipelines allow code to be delivered to production without enforced approval gates, reviews, or merge checks. Attackers who compromise a single developer account can ship malware directly to production. Organizations should implement mandatory code reviews, enforce status checks before a merge, and restrict who can approve changes to protected branches.

2. CICD-SEC-2: Inadequate identity and access management

This risk stems from overly permissive service accounts, reused credentials across pipeline stages, and the absence of multi-factor authentication on CI/CD platforms. Build systems often run with administrative privileges far beyond what they actually need. Enforcing identity federation and limiting each service account to a single pipeline stage helps contain the impact of any single credential compromise.

3. CICD-SEC-3: Dependency chain abuse

Open-source package repositories are often targeted by attackers aiming to inject malicious code into trusted dependencies. According to Group-IB’s High-Tech Crime Trends 2026 report, npm and PyPI have become prime targets of this tactic. A compromised maintainer account can cause malicious updates to cascade to millions of downstream applications within hours.

Case in Point: Group-IB’s Business Email Protection team investigated a real NPM supply chain compromise in which a threat actor phished developer Josh Junon via a campaign impersonating npm Support. The attacker then modified 20 popular npm packages by inserting a JavaScript clipper into their source code, targeting packages that together account for 2.8 billion weekly downloads.

In a separate post, Group-IB researchers detailed how Lazarus used npm packages to impersonate popular libraries, including is-buffer, eslint, and react-related utilities. Developers installed them as part of spearphishing campaigns disguised as job interviews, unknowingly deploying credential stealers and Python backdoors.

4. CICD-SEC-4: Poisoned pipeline execution

Attackers exploit this risk to run arbitrary code during the build. Workflow definitions can be modified in pull requests to exfiltrate secrets or execute arbitrary commands within the runner environment. We saw this same pattern in the tj-actions/changed-files compromise in March 2025, when attackers injected a payload that dumped CI/CD secrets directly into publicly available workflow logs.

5. CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

This risk occurs when pipeline jobs have broader access to resources, environments, and secrets than is actually needed for their specific purpose. Using production deployment credentials in a test-stage job violates the least-privilege principle and increases the impact of any compromise. Limit each job to only the secrets and environments it actually requires, and deploy to production using dedicated runners.

6. CICD-SEC-6: Insufficient credential hygiene

Poor credential hygiene leaves pipelines exposed. Common failures include hardcoded secrets in configuration files, long-lived tokens that never rotate, and environment variables that remain accessible throughout the pipeline. 

The risk worsens over time because many organizations still do not automatically rotate credentials, so leaked secrets often remain valid for months or even years. CI/CD runners make this worse because they handle credentials constantly, and a single compromised runner can expose every secret that passes through it.

Pro Tip: Do not store secrets as environment variables in pipeline configuration files. Store them in a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, and rotate them on a fixed schedule. CI tokens should be short-lived, expiring in minutes, not days.

7. CICD-SEC-7: Insecure system configuration

CI/CD platforms become vulnerable when they run with default configurations that enable debug mode, verbose logging of secrets, or unrestricted network access from build runners. 

In 2025, over 70 security vulnerabilities were found in Jenkins, most of them related to plugins, and the Shadowserver Foundation detected over 45,000 internet-exposed Jenkins servers that were still vulnerable to known exploits. Hardening CI/CD platform configurations should be part of the initial deployment and reviewed after every major version upgrade.

8. CICD-SEC-8: Ungoverned usage of third-party services

This risk arises when third-party integrations connect to CI/CD platforms via OAuth tokens or webhooks that grant excessive permissions. Each integration expands the trust boundary without a corresponding review of what access it holds. Maintain an inventory of all connected third-party services and audit their permission scopes quarterly.

9. CICD-SEC-9: Improper artifact integrity validation

Artifact integrity gaps occur when build outputs are not signed, hashed, or verified before deployment. Without integrity validation, an attacker who compromises the artifact registry can replace a legitimate build with a backdoored version. Adopt a framework like SLSA (Supply-chain Levels for Software Artifacts) to enforce provenance verification at each handoff between pipeline stages.

10. CICD-SEC-10: Insufficient logging and visibility

Visibility gaps emerge when pipeline events are not logged, monitored, or retained for investigation. Without audit trails covering who triggered a build, what changed, and what was deployed, incident response teams cannot reconstruct the attack timeline. Forward CI/CD platform logs to a centralized SIEM and set retention policies that meet both compliance requirements and investigation needs.

How to Secure Your CI/CD Pipeline

Securing a CI/CD pipeline is comprehensive and requires controls mapped to each stage of the delivery process. The details below provide a step-by-step walkthrough of the security controls that DevSecOps teams need to implement at each stage of the pipeline.

1. Source stage: protecting code repositories and access controls

The source stage is where code enters the pipeline. If access control is weak here, everything downstream inherits that weakness. Apply role-based access control to all users. Set up branch protection rules so that merges require pull request reviews and passing status checks. Use signed commits to verify author identity. For service accounts used in automation, scope IAM permissions to the minimum needed for the job, nothing more.

2. Build stage: secrets detection, SAST, and dependency scanning

The build stage is when code is compiled, and dependencies are resolved, making it the right point to catch vulnerabilities before they reach an artifact. Perform Static Application Security Testing (SAST) and Software Composition Analysis (SCA) for each build. Add secrets scanning to flag hardcoded credentials before build artifacts are created.

Build stage vulnerability scanning contributes to a broader vulnerability management program, providing input for triage, prioritization, and remediation tracking.

Pro Tip: Run SAST and SCA scans in parallel rather than sequentially. Parallel execution reduces pipeline time without reducing coverage, removing the most common objection developers raise to adding security gates to CI/CD workflows.

3. Test stage: DAST and container scanning

In staging, run Dynamic Application Security Testing (DAST) against the deployed application to catch vulnerabilities that only appear at runtime. Scan container images for known vulnerabilities and misconfigurations before they move forward. Use Infrastructure as Code (IaC) scanning to flag cloud misconfigurations in Terraform, CloudFormation, or Kubernetes manifest files.

4. Deploy stage: artifact integrity and runtime security

Sign all build artifacts and ensure verified image policies are in place so that only trusted containers can reach production. Use automated security gates that deny anomalous builds from proceeding. Create a clear separation of duties between staging and production, ensuring different credentials and approval workflows.

Pro Tip: Implement admission controllers in Kubernetes that reject unsigned images at the cluster level. This creates a hard enforcement boundary that cannot be bypassed by individual pipeline configurations.

CI/CD Security Best Practices

The following CI/CD security best practices focus on the operational and governance controls that support the technical hardening discussed earlier.

1. Enforce least privilege across the entire pipeline toolchain

Overprivileged service accounts are still one of the easiest ways for attackers to gain a foothold in CI/CD environments. The controls below help reduce that exposure.

• Scope each pipeline job’s credentials to only what that phase actually needs.
• Replace static API keys with short-lived tokens that rotate automatically.
• Review third-party integrations every quarter and revoke OAuth tokens that are no longer in use.
• Keep human and machine identities separate, with distinct access policies for each.

2. Automate security gates without blocking developer velocity

Security controls that impede the CI/CD flow get turned off or circumvented. Create gates that have rapid feedback and fail only on confirmed, high-severity issues.

• Configure scan timeouts in accordance with existing build-time tolerances.
• Use risk-based thresholds to separate critical findings from noise.
• Provide developers with clear remediation guidance directly in the CI/CD output.
• Monitor false-positive rates and calibrate policies to maintain high developer trust.

3. Continuous monitoring and pipeline-specific incident response playbooks

To achieve full CI/CD pipeline security, monitoring must go beyond whether a build succeeded or failed. Detect abnormal activity such as builds triggered by unknown accounts, configuration file changes, or access from unexpected IP ranges.

• Correlate pipeline events with broader security signals by integrating CI/CD audit logs into your SIEM.
• Create incident-response playbooks tailored to pipeline-compromise scenarios.
• Establish escalation paths that involve both security operations and platform engineering teams.

4. Track security metrics that prove improvement over time

To measure CI/CD pipeline security over time, you need metrics that tie to both risk reduction and engineering outcomes. CI/CD security tools generate data, but their value lies in monitoring trends across releases.

• Vulnerability detection rate: Percentage of findings caught before code reaches production.
• Mean time to remediate: Average time between detection and fix for security findings in pipeline scans.
• Security test coverage: Proportion of repositories with SAST, SCA, and secrets scanning enabled.
• Security-related build failures: Track whether failures decrease over time as developer awareness improves.

Where Group-IB Fits in Your CI/CD Security Program

SAST, DAST, and SCA scanners handle known vulnerability patterns in code and dependencies well. But they have blind spots. They won’t catch a cloud misconfiguration introduced during deployment, and they have no visibility into active threat campaigns targeting developer credentials or CI/CD toolchains. Group-IB covers both of those gaps.

Group-IB Cloud Security Posture Management evaluates CI/CD pipelines for misconfigurations during development workflows, not after code reaches production. Most posture tools only assess live cloud environments, but that is too late. Misconfigurations usually originate in the pipeline itself, and that is where this tool catches them.

Group-IB Threat Intelligence tracks active campaigns targeting CI/CD infrastructure: phishing operations aimed at developer accounts, malicious packages published to npm and PyPI, and compromised OAuth tokens circulating on dark web forums. These are threats that static analysis and dependency scanners lack the means to detect.

Both integrate into existing CI/CD workflows. Posture findings and threat indicators feed into your SIEM and incident response playbooks, so when a misconfiguration is detected or a supply chain indicator fires, there is a documented response path rather than ad hoc manual triage. Detection connects to remediation inside your SDLC, and pipeline security issues get resolved before code ships.

Contact Group-IB experts today to see how pipeline-aware posture monitoring and threat intelligence work together to secure applications before deployment.