Introduction: Lessons from Networking
In networking, the separation of the control plane and data plane is foundational. The data plane moves packets from point A to point B, while the control plane makes decisions such as routing, path selection, and policy enforcement.
This separation was intentional. It provided resilience, modularity, and security. Each plane could be optimized or attacked independently, unless the integration point (such as BGP route injection) was mishandled.
The same thinking applies far beyond networking. Yet in many domains, we either ignore it or unknowingly mix the two. When the control and data layers are conflated, visibility drops, attack surfaces expand, and accountability is muddled. This piece explores where similar patterns exist in modern systems, why separation matters, and how it can reshape our threat modeling.
Key Examples of Control and Data Planes Beyond Networking
Git and GitHub (Version Control)
- Data Plane: Git repositories (code, history, commits).
- Control Plane: GitHub/GitLab/Bitbucket web UIs, permissions, CI/CD triggers.
Why it matters: A compromised GitHub token may not breach the Git server directly, but it can manipulate access, inject code, and trigger builds silently.
Case Study: Shai Hulud Worm — A worm-like malware actively hunted for GitHub tokens. Using compromised control tokens, it created repositories, exposed private repos, and attempted to steal secrets, all without directly breaching Git data.
GitHub SSH vs Token Blindspots
- Data Plane: Git operations using SSH keys.
- Control Plane: GitHub tokens, web UI, and associated monitoring.
Why it matters: While GitHub provides excellent visibility and logging for token usage, monitoring for SSH key based activity is far less transparent to regular users. This creates a blind spot where data plane operations may occur without the same level of auditability.
Case Study: keychecker We release this tool based on our research that there is no publicaly or freely available logging for the actions done by ssh key. We weaponized this by creating a username detection as well as private repository bruteforcing tool. SSH keys could exfiltrate or manipulate repositories without triggering the same detailed logs available for token-based access. This asymmetry highlights the importance of balanced observability across both authentication methods.
AWS Console and EC2 (Cloud Infrastructure)
- Data Plane: EC2 VMs, EBS volumes, S3 buckets.
- Control Plane: AWS Console, IAM, CloudFormation APIs.
Why it matters: A VM may have its own security, but access to the AWS Console can stop, modify, or snapshot it instantly. The true blast radius often lies at the control level.
Case Study: Scattered Spider – Attackers used social engineering to gain access to cloud admin accounts, bypassing MFA and escalating control plane access. With console-level control, they halted services and accessed sensitive data without breaching workloads directly.
Kubernetes and Containers (Cloud-Native World)
- Data Plane: Pods, containers, network traffic.
- Control Plane: Kubernetes API server, scheduler, etcd.
Why it matters: Access to the API server can reroute services, inject containers, or escalate privileges across the cluster without exploiting individual apps.
Case Study: Ingress-nginx CVE-2025-1974 — Multiple research reports highlighted open Kubernetes dashboards discovered in cloud environments. Attackers leveraged exposed APIs to deploy cryptominers, demonstrating how control-plane compromise can bypass hardened container workloads.
CI/CD Pipelines and Build Artifacts (DevOps)
- Data Plane: The code being built and the artifacts produced.
- Control Plane: The pipeline configuration, runner permissions, webhook triggers.
Why it matters: A poisoned pipeline definition can introduce backdoors into every software release.
Case Study: XZ Utils Backdoor — Attackers compromised a critical open-source project by tampering with its build process. Control of the pipeline allowed insertion of malicious code into distributed binaries, showing how CI/CD control-plane compromise bypassed direct code review.
Emerging Domain: ML Pipelines
- Data Plane: Training datasets, model weights.
- Control Plane: MLflow servers, training orchestration scripts.
Why it matters: Attacking the control system that governs training jobs can produce poisoned or biased models, even when the raw data remains untouched.
Case Study: LLM Supply Chain Attacks 2025 — Research demonstrated poisoning through ML orchestration layers. By compromising retraining pipelines, attackers introduced subtle manipulations into large language models without directly altering raw training data.
When Planes Collide: Hidden Complexity
In many systems, data and control planes are not clearly separated. Sometimes they blend by necessity, sometimes by oversight. This overlap creates fertile ground for subtle security gaps and operational failures.
Common symptoms:
- Developers using production credentials in CI builds.
- Terraform applying changes to live infrastructure with no approval loop.
- Admin interfaces that allow both configuration and direct data manipulation.
Fixing It: Introduce approvals, reduce cross-plane permissions, and isolate CI agents from direct data access. Treat each bridge as a security boundary.
Threat Modeling: Planes and Integration Points
Instead of one flat threat model, think in three layers:
- Data Plane Threats: Direct attacks such as data corruption or unauthorized access.
- Control Plane Threats: Configuration tampering or privilege escalation.
- Integration Point Threats: Tokens, API keys, and session handling that bridge the two.
Signs You Have Blind Spots
- Lack of distinct audit logs for configuration and runtime actions.
- Shared or reused credentials across deployment and operations.
- Absence of multi-factor authentication on CI/CD or admin tools.
- Monitoring limited to resource metrics without tracking configuration changes.
- Privileged API keys stored insecurely or used across multiple services.
These patterns often point to weak integration boundaries between control and data planes. A practical example is GitHub SSH access: token usage is logged extensively, but SSH key activity is less visible to end users. This creates a data plane blind spot that attackers can exploit without triggering the same monitoring controls.
Practical Advice: Start Thinking in Planes
- Design: Sketch control and data separately. Identify meeting points and who controls what.
- Threat Model: Independently ask: What if control is compromised? What if data is corrupted?
- Operate: Treat control plane activity such as admin console logins as higher sensitivity events than routine data plane activity.
- Audit: Ensure logs capture control actions distinctly from data access events.
Many catastrophic breaches happen not because one plane was ignored, but because either control or data was left exposed or misunderstood. Both must be treated as equally important and capable of being attacked separately.
Closing Thought
In complex systems, everything may appear interconnected. Clarity comes from deliberately separating control from data and modeling them both independently and together.
Failures do not usually arise because one plane is inherently weak. They occur when the integration points between the two are overlooked, or when either control or data is undervalued. Both planes represent distinct attack surfaces and both deserve equal attention in design, operations, and monitoring.
Start seeing the world in planes, and secure each one on its own terms.
<SelfPromotion>
Software Supply Chain is one of our core research areas and we also offer various trainings on this Domain. Below are some of our upcoming trainings.
</SelfPromotion>