Securing CI/CD Pipelines: Addressing the Attack Surface in Software Supply Chains
This article highlights the Cordyceps vulnerability pattern, which exposed weaknesses in CI/CD workflows across major organizations, allowing unauthenticated GitHub accounts to compromise open-source supply chains. It emphasizes that CI/CD pipelines are a critical part of the attack surface, not just configuration, and advocates for treating them with the same security rigor as production systems. The core issue lies in overlooking workflow security, permissions, and untrusted input paths during development and automated scanning.
Read original on The New StackThe Cordyceps Flaw: A Wake-Up Call for CI/CD Security
The Cordyceps vulnerability pattern, discovered by Novee Security, demonstrated how flaws in CI/CD workflows could enable attackers to hijack trusted processes and compromise open-source software supply chains. This particular weakness allowed unauthenticated GitHub accounts to exploit vulnerabilities in YAML-based workflows. The widespread impact, affecting companies like Microsoft and Google, underscores a critical oversight in many development practices: treating CI/CD configurations as less security-sensitive than application code.
CI/CD as a Production System
Pipelines hold significant power, including access to source code, secrets, and deployment capabilities. A single mistake or exploit in a workflow can have far-reaching downstream consequences, making them as critical as any production system. Developers and security teams must shift their mindset to treat CI/CD workflows with the same level of scrutiny as other production surfaces.
Why CI/CD Risks Are Missed
Traditional code reviews often overlook CI/CD risks because developers tend to view workflow YAML files as mere configuration rather than executable, security-critical code. This perspective leads to a failure in asking crucial security questions, such as:
- Who can trigger this workflow?
- What permissions does it receive upon execution?
- Are sensitive secrets exposed or accessible?
- Can untrusted pull request data influence privileged steps within the workflow?
Furthermore, many security scanners are not designed to detect these contextual vulnerabilities. They typically look for known-bad patterns or specific dangerous strings, rather than tracing the path of untrusted input to a powerful action, which requires understanding the workflow's permissions and potential downstream impact.
Shifting to a Security-First CI/CD Mindset
To mitigate these risks, the article advocates for a fundamental shift in how developers and security teams approach CI/CD. This includes: 1. Comprehensive Review: Anchoring each CI/CD workflow review in three key questions: What triggered it? What permissions did it have? What can an outside input reach using those permissions? 2. Adversarial Thinking: Thinking like an attacker, starting from a potential end goal (e.g., code injection, secret exfiltration) and working backward through the workflow to identify vulnerable paths where untrusted input could escalate privileges. 3. Advanced Scanning: Moving beyond simple pattern matching to security scanners that can understand the context of input paths, permissions, and potential impacts within the workflow.
Key Question for CI/CD Security
Instead of asking 'Is this workflow safe?', a more effective question is: 'Can untrusted input move from a low-privilege place into a high-privilege action?' This reframing encourages a more thorough analysis of potential attack vectors within the CI/CD pipeline.