Introduction

Modern cloud breaches rarely start in production.

They start in code.

A leaked GitHub Personal Access Token (PAT), an over-privileged CI/CD workflow, or a compromised developer tool can quietly become the entry point to your entire cloud control plane. What follows is not a vulnerability exploit in the traditional sense—but a chain reaction of trust abuse across systems that were never designed to be defended in isolation.

This is the reality of code-to-cloud attacks.

The New Kill Chain: Code → CI/CD → Cloud

Traditional security models assume a clean separation between:

• Source code
• Build systems
• Cloud infrastructure
• Production environments

In reality, these layers are tightly coupled by credentials, automation, and implicit trust.

A modern code-to-cloud attack typically unfolds like this:

• Initial Access: GitHub PAT Compromise
• Privilege Expansion: CI/CD Abuse
• Credential Harvesting: Cloud Secrets Exposure
• Impact: Cloud Control Plane Takeover

No malware required. No zero-day required. Just misaligned trust.

Step 1: GitHub PAT — The Soft Underbelly

GitHub PATs are widely used for:

• Local development
• CI/CD authentication
• API access
• Automation scripts

The problem?

They are often:

• Over-scoped (repo + org + workflow access)
• Long-lived
• Stored in plaintext configs, scripts, or logs
• Accidentally committed or exfiltrated from build systems

Once a PAT is compromised, an attacker may gain:

• Read or write access to repositories
• Ability to modify GitHub Actions workflows
• Access to CI secrets via workflow execution

At this point, the attacker is no longer outside your perimeter. They are operating as a trusted developer.

Step 2: CI/CD — Where Trust Becomes Power

CI/CD systems sit at the most dangerous intersection in modern infrastructure:

• They read source code
• They access secrets
• They deploy infrastructure
• They talk directly to cloud APIs

Attackers with repo or workflow access can:

• Modify pipeline steps
• Inject malicious commands
• Exfiltrate environment variables
• Abuse build-time permissions

Common misconfigurations that accelerate compromise:

• Broad GITHUB_TOKEN permissions
• CI roles with admin-level cloud access
• Secrets shared across environments
• No approval gates for workflow changes

From here, the attacker’s goal is simple:

Get cloud credentials.

Step 3: Secrets to Cloud Credentials

CI pipelines frequently expose:

• AWS access keys
• GCP service account tokens
• Azure service principals
• Terraform backends
• Kubernetes kubeconfigs

Even “temporary” credentials are enough.

Once obtained, attackers can:

• Call cloud APIs directly
• Enumerate IAM roles
• Create new identities
• Disable logging
• Establish persistence

At this stage, the breach has left the application layer entirely.

Step 4: Cloud Control Plane Compromise

This is where the real damage happens.

With access to the cloud control plane, attackers can:

• Create backdoor IAM users or roles
• Spin up cryptomining or C2 infrastructure
• Snapshot databases and exfiltrate data
• Modify network security rules
• Deploy malicious workloads at scale

Worse, these actions often look like legitimate automation:

• API calls from known IPs
• Authenticated requests
• No malware signatures
• No exploit payloads

Traditional detection tools struggle here because nothing is technically “broken.”

Why Code-to-Cloud Attacks Are So Hard to Detect

Because every step abuses intended functionality.

• GitHub PATs are meant to automate access
• CI/CD pipelines are meant to deploy
• Cloud APIs are meant to be called programmatically
• IAM roles are meant to be assumed

The failure is not a single control—it’s lack of contextual visibility:

• Which repo change led to which pipeline?
• Which pipeline accessed which secret?
• Which secret enabled which cloud action?
• What is the real blast radius?

Without that context, teams investigate incidents in fragments, never seeing the full chain.

The Security Shift Required

Stopping code-to-cloud attacks requires moving beyond point solutions.

You need to:

• Treat source control as production-critical
• Minimize and continuously review token scope and lifetime
• Enforce least privilege in CI/CD
• Correlate repo events → pipeline activity → cloud actions
• Understand business impact, not just alerts

This is where modern Application Security Posture Management (ASPM) becomes essential—connecting identity, code, infrastructure, and runtime risk into a single narrative.