Council Post: CI/CD Security Risks Leaders Should Review Before Attackers Do

getty

As software teams increasingly depend on open-source components and automated CI/CD pipelines, the permissions and workflows connecting those systems deserve closer scrutiny. Because pipelines can interact with source code, credentials, cloud infrastructure and production environments, they may hold far more authority than any single development task requires.

If an attacker compromises a dependency, build process or other link in the software supply chain, overly broad pipeline privileges can turn that initial foothold into a much wider breach. Here, Forbes Technology Council members highlight CI/CD permission and workflow decisions that technology leaders should regularly reassess to reduce unnecessary access and strengthen the development pipeline.

Separate Artifact Fetch And Publish Permissions

Lock down the pipeline’s write path to the artifact registry. The nightmare scenario isn’t a malicious PR; it’s a hijacked build agent quietly injecting poisoned code into a signed, trusted container. Segment permissions ruthlessly: The tool that fetches open-source libraries should never be the same identity that pushes to production. Review that proxy’s scope. If it can publish, an attacker who slips into a build log already owns your next deployment. - Eshaan Jain, Mphasis Silverline

Treat Pipelines As Privileged Identities

Here’s what teams forget: Your build pipeline is basically a user, and it’s usually the most powerful one you’ve got. It can reach production and holds every secret; no human would ever be handed that much authority. A single bad dependency doesn’t need to break in; it just asks the pipeline to do the damage for it. Review your build system like it’s a privileged person, because to an attacker, it already is. - Ganesh Ariyur, Transform Smarter

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?

Pin External Actions To Immutable Hashes

Stop trusting mutable version tags (like @v4) in your CI/CD pipelines. This year’s major supply chain exploits proved that attackers can hijack trusted third-party repositories and force-push malicious code onto existing release tags. Instead, enforce SHA-256 hash pinning for all external actions. Locking dependencies to an immutable cryptographic hash ensures you only run the exact, audited code you intended. - Mahendran Chinnaiah

Delay Adoption Of New Package Releases

Review how fast your pipeline consumes new releases. Most compromised packages are caught and pulled within days, but automation merges them within hours. Speed isn’t the goal; it’s the attack surface. A short delay between “published” and “trusted” costs almost nothing and closes the window attackers actually use. - Ankit Kumar Honey, GitHub Inc. (Microsoft)

Apply Least-Privilege Permissions To Runners

The decision most worth reviewing is what permissions your CI/CD runners carry by default. Most are assigned AdministratorAccess or broad IAM policies because scoping them takes time. When tj-actions/changed-files was compromised in March 2025, over 23,000 repositories were exposed within hours. Least-privilege runner permissions cap the blast radius when a pipeline becomes an entry point. - Manas Chaudhari, Meta

Restrict Pipelines To Approved Package Sources

Your CI/CD pipelines pull from the public internet by default, and nobody reviews them due to the sheer volume of agentic development. At our company, we proxied all package registries through Cloudsmith with an approved allowlist. If a package isn’t on it, the build fails. One configuration change eliminated an entire class of supply chain attacks. Check whether your pipeline can pull any package from anywhere. Most can. - Gaurav Singal, ConstructConnect

Secure Rollback Workflows Like Forward Deployments

Review whether rollback workflows bypass normal production approvals. Many organizations secure forward deployments yet allow emergency rollbacks with broad permissions and minimal verification. Attackers love trusted shortcuts. Every rollback should verify artifact integrity, require independent authorization and leave the same immutable audit trail as a forward release. Recovery paths deserve equal security. - Jagadish Gokavarapu, Wissen Infotech

Limit And Shorten Production Credentials

Review who can mint production tokens from CI. Too many pipelines have the keys to the resort, not just the linen closet. Make deploy credentials short-lived and environment-scoped, and require human approval for sensitive changes. Automation should carry bags, not open the vault. - Joel Frenette, TravelFun.ai

Protect Deployment Gates From Pipeline Changes

Review whether a pipeline can modify the tests, scanners or policy rules that decide whether it may deploy. A workflow that can change its own gate is both builder and auditor. Keep those controls in a separately protected repository, require independent approval and record the policy version with each release. Otherwise, a green build may only prove the pipeline rewrote the definition of “green.” - Mani Padisetti, Almost Magic Tech Lab

Isolate Shared And Self-Hosted Runners

Decision leaders should audit the self-hosted runners shared across repos or teams. Unlike ephemeral cloud runners, they persist state between jobs, so one compromised build can silently plant malware the next job inherits. Use single-use, isolated runners per job; wipe state after each run; and never let public-repo workflows share runner pools with production pipelines. This way, things will be clean and easy to manage to ensure attackers do not exploit them. - Dan Sorensen, Nexus Security Advisors

Restrict Untrusted Pull Request Permissions

Review whether CI pipelines can write back to source control or trigger production changes from untrusted pull requests. That single convenience can become an attacker’s shortcut. Build systems should assume code contributions are hostile until proven otherwise, with strict token scope, isolation and approval gates. - Rohit Muthyala, ZoomInfo Technologies Inc.

Verify Open-Source Software Provenance

Software teams need a reliable, verified source for open-source software. Beyond security proxies or firewalls, organizations should implement application-aware pipelines that deliver attested, vulnerability-free code. Just as teams review code for bugs, they must verify the provenance and security of the source itself to secure their software supply chain. - Javed Hasan, Lineaje

Scope Secrets To Individual Pipeline Steps

Review which secrets and environment variables are accessible across pipeline stages versus scoped to the step that needs them. Most pipelines expose credentials broadly because it’s easier to configure once than to scope precisely. That means a compromised early build stage can access production secrets it has no reason to touch. Secrets should be scoped to the step that uses them and rotated frequently enough that a leaked credential has a short useful window. - Dan Haiem, AppMakers USA

Limit Who Can Change Or Run Pipelines

One thing I’d review first is who can change or run the CI/CD pipeline. If those permissions are too broad, an attacker could slip malicious code into a trusted build. Keeping permissions minimal, protecting pipeline configurations and requiring code reviews are simple but effective ways to reduce that risk. - Muhammad Affan Habib, Sharjah Maritime Academy

Match Runner Access To Each Task

Review what your CI/CD runners can access on a normal Tuesday. Most pipelines run with permissions scoped for the hardest job they might ever do, not the routine one they do daily. That gap is where attackers live. A compromised build step with production database credentials attached is a bigger blast radius than most teams model. Scope runners to the task, rather than the ceiling. - Nidhi Jain, CloudEagle.ai

Require Human Approval For AI-Generated Code

Review whether your AI agents can merge their own code. Teams are wiring coding agents into CI/CD faster than they’re defining what those agents can touch—an agent with merge rights is a new insider threat with superhuman speed. In our pipeline, agents open pull requests on isolated branches, but a human merges every one, and signed webhooks verify each handoff. AI proposes. Humans approve. Anything looser is an incident report waiting for a date. - Kiran Kodithala, N2N Services, Inc.

Restrict Build Runner Network Egress

One thing leaders skip is outbound network rules for build runners. A pipeline can look perfectly locked down, but if the runner has open internet egress, a single malicious script can quietly ship secrets and source code to an outside server during the build itself. Locking egress to an approved allowlist closes an exit most teams never think to check. - Hari Sonnenahalli, NTT Data Business Solutions

Govern Conditions For Automated Pipeline Access

The conditions that trigger automatic pipeline access deserve thorough examination. With agentic AI becoming common in the CI/CD pipeline, it’s essential to ensure that AI agents running the protocol can identify any known vulnerabilities and are able to impose a strict breakout rule. Governance frameworks must keep evolving to evaluate the automation conditions, maintaining pipeline sanctity. - Kris Lahiri, Egnyte

Verify Compiled Artifacts Before Deployment

Review where CI/CD workflows allow compiled software to execute or deploy, not just where source code is reviewed or approved. With more AI coding tools, agents and open-source dependencies, security based on source analysis, signatures or pipeline approvals becomes less reliable. Before deployment, extend zero-trust principles to the compiled artifact, verifying what the software can do and whether those behaviors are authorized before it is trusted to run. - Ken Ammon, CodeHunter