Security
IronCD is built to provide strong isolation, data integrity, and compliance assurance without adding complexity to your workflow. This page describes the key parts of IronCD’s security model and how we protect each job from interference or data exposure.
Threat Model
IronCD’s threat model assumes that customer workloads may execute untrusted or arbitrary code, and that preventing cross-tenant access, data leakage, and privilege escalation is paramount. The control plane, runner hosts, and network layers are designed to enforce strict trust boundaries: the control plane cannot be influenced by user code, and runners cannot access customer data belonging to other tenants. We focus on isolating workloads from one another, protecting secrets in transit and at rest, and ensuring that a compromise in any single job or host cannot impact other users or the service as a whole.
Compliance
IronCD’s security practices align with established industry frameworks. A SOC 2 Type I audit is currently underway, with Type II certification planned once operational controls have been observed over time.
We continuously review our systems against SOC, ISO 27001, and CIS benchmark requirements to maintain consistent security posture and accountability.
Isolation Model
Every build runs inside its own dedicated virtual machine that is provisioned exclusively for that workload. These VMs are launched using hardware-assisted virtualization via KVM, which provides CPU- and memory-level isolation between workloads. VM disks are destroyed immediately after each job completes. No data, credentials, memory, or state carry over between runs.
Authentication
Each workflow is secured through Just-In-Time (JIT) authentication. When a job starts, IronCD creates a one-time access token scoped specifically to that run. Tokens are injected into the runner at boot, used during execution, and automatically destroyed once the job finishes.
Tokens aren’t persisted on the host, can’t be reused, and never provide access beyond the boundaries of a single workflow.
Host Security
All IronCD runners run on dedicated bare-metal hosts that are hardened and continuously maintained. Kernel and firmware updates are applied on a regular schedule. Each host enforces custom AppArmor profiles to restrict system access.
Host-level access is limited to authorized operational staff, and all actions are logged and reviewed. Hosts are not exposed to the internet or any external networks.
Network Egress Security
IronCD enforces multiple layers of network protection. Outbound connections from runners are filtered at the kernel level, allowing only approved destinations defined in your organization’s policy. All egress activity is monitored, logged, and made available for audit or compliance review.
Customers can define precise network policies to control what their builds can reach, ensuring workflows stay isolated and predictable. Runners are not permitted to access any resources outside of the defined network policies. Runners may only communicate over HTTPS - other protocols, such as HTTP or SSH, are blocked.
Unless otherwise specified, IronCD cannot decrypt traffic between your runners and external hosts. Egress filtering is performed using SNI, which does not reveal the contents of the traffic.
Vulnerability Reports
If you believe you have found a security vulnerability in IronCD, please report it to security@ironcd.com. We take security very seriously and will work with you to address any issues promptly.