Beyond the Green Pipeline: Analyzing CI/CD Attack Chains That Evade Security Scans

Introduction: The Illusion of a 'Green' Pipeline

You look at the dashboard at 8:00 AM, and everything is green. The scanners have finished, the reports are clean, and the CI/CD pipeline seems solid. It is a comforting sight, but it is often a trap. We have built our security posture around the assumption that if the file-level scans pass, the pipeline is safe.

As we grapple with the increasing complexity of artificial intelligence cybersecurity threats, this assumption is breaking. Attackers aren't necessarily looking to place malicious code in a single file anymore. They’re looking at the design of the entire pipeline—the composition—and finding ways to exploit how components interact when they trust a pull request too much.

This is the reality of modern CI/CD: an environment where a perfectly valid YAML file can be a gateway to a full system compromise. If we want to move beyond a false sense of security, we need to understand exactly how these attack chains operate at scale.

Tutorial: Artificial Intelligence AI Cybersecurity and Cordyceps

Researchers at Novee Security recently shed light on a class of CI/CD weaknesses they’ve dubbed 'Cordyceps'. If you haven’t heard the term, it deserves your attention. These aren’t traditional vulnerabilities where a scanner can flag a specific line of code as "bad." Instead, Cordyceps is a composition-based vulnerability.

Think of it as a chain reaction. A single workflow file might look perfectly fine. But when it interacts with a pull_request_target or workflow_run trigger, it can behave in ways you didn't anticipate. Attackers use these triggers to execute code in a privileged context—the base repository—rather than the untrusted context of a fork.

Consider the primitives that make this possible:

• Command injection: Inserting attacker-controlled data, like a branch name, directly into a run step.
• Code injection: Evaluating attacker-controlled input as JavaScript at runtime.
• Cross-workflow privilege escalation: Writing untrusted data from a low-privilege workflow into an artifact that a high-privilege workflow reads and executes.

No single step in this chain is inherently malicious, which is what makes these attack patterns so slippery. The vulnerability exists between the steps, not in the steps. As practitioners applying AI cyber security practices, we often focus on the granular, but these multi-stage attacks demand we look at the bigger picture of how our automation environments are connected.

Why Traditional Scanning Falls Short

So why do the scanners miss it? Because scanners are usually designed to analyze individual files for static markers. They look for hardcoded secrets, insecure command usages, or outdated dependencies in the YAML. They don’t analyze the broader composition of the entire CI/CD pipeline.

A SAST or DAST scanner sees a well-formed YAML file doing exactly what the configuration says it should. It cannot tell that this perfectly legitimate configuration is being subverted by an attacker to gain persistent write access.

This lack of visibility is why we’re seeing attackers shift toward chaining these seemingly innocuous steps. When we rely solely on these tools, we create a blind spot that automated AI tools are actually helping to exploit. AI-generated workflows can reproduce the same insecure CI/CD patterns across thousands of repositories, accelerating the vulnerability surge in software supply chains where each one looks just as "green" and valid to the scanner as the last.

Whether you're developing autonomous agents or standard application code, this gap in governance is critical. We need to move from "does this file look secure?" to "does this component have a governed, verifiable origin?" If you're interested in the larger shift toward more intelligent infrastructure, check out this perspective on transforming cybersecurity infrastructure.

Hardening and Governance Strategies

How do we secure our pipelines against this? It starts by acknowledging the trust boundary. If you’re a developer, you need to be intentional about what your CI/CD environment trusts.

Start with these fundamental practices:

1. Prefer pull_request over pull_request_target: Always use the untrusted context for PRs when possible.
2. Avoid checkout in privileged workflows: Never checkout untrusted pull request code inside a privileged environment.
3. Use environment variables: Pass event data through quoted environment variables to avoid injection risks.
4. Pin third-party actions: Use a commit SHA instead of a moving tag.

But hardening isn't just about tactical changes in YAML files. It’s about securing the entire pipeline. We need automated governance, like those provided by the OpenSSF Scorecard, to get a holistic view of the security posture. Organizations are increasingly looking at multi-agent environments to manage this complexity, and while that's promising, those agents themselves need to be secured with a focus on provenance and least privilege.

The research coming out of organizations like IBM continues to highlight the need for robust security frameworks that handle the inherent risks in these distributed systems. We must shift the focus from simple file-level oversight to perimeter-based pipeline security that understands the intent and origin of every component.

Conclusion

The 'green' light on your dashboard is just one signal, and it’s clearly not enough in the era of automated, agentic workflows. Attackers have figured out that they don't need to break your security scanners—they only need to work within the rules your scanners were never written to check.

The Cordyceps class of vulnerabilities isn't going to disappear on its own. As we integrate more AI into our engineering and agentic workflows, the sheer volume of CI/CD configuration will continue to outstrip our ability to manually review it.

We must stop trusting our pipelines based on file-level checks alone and begin asserting governance at the source. It’s time to move toward a model where every workflow and component entering your build pipeline carries verifiable provenance. Governance must operate at machine speed, because manual review at the far end of the pipeline is already a lost cause.

Your pipeline should be governed, not just scanned. It's time to start looking at what's really running through yours.