Drone CI is the container-native build system that started as a lightweight alternative to Jenkins and became, over the course of several acquisitions, the foundation of what is now Harness CI. The OSS version is still widely deployed, and a meaningful number of organizations are running Drone v2 in production with configurations that date back to the pre-Harness era. The security considerations for those deployments are worth a careful look, both because they are different from Jenkins's and because the transition from Drone OSS to Harness has created a long tail of installations that no longer receive regular updates.
This post covers Drone CI security as it stands in Drone v2.23, the last meaningful OSS release before the Harness migration. It focuses on runner isolation, secret handling, plugin risks, and the specific considerations for organizations still running the OSS version. It is written for teams operating Drone today, not for teams evaluating whether to adopt it.
The runner model and isolation guarantees
Drone pipelines run as a series of containers, one per pipeline step, all sharing a common workspace volume. The Drone server orchestrates the pipeline by dispatching steps to a runner, and each runner is responsible for executing the container steps in order. The available runner types are the Docker runner, the Kubernetes runner, the SSH runner, and the Exec runner, with meaningfully different isolation properties.
The Docker runner is the default and the most commonly deployed. It runs each pipeline step as a Docker container on a host shared across multiple pipelines. The isolation is container-level, which means a step that exploits a container escape vulnerability has access to the Docker socket and from there to every other pipeline running on that host. This is not a theoretical risk — container escapes have been a steady stream of CVEs over the past five years, and Drone's default configuration does not restrict which images steps can use.
The Kubernetes runner is better, because each pipeline runs in its own pod with pod-level isolation and Kubernetes RBAC restricting what the pod can do. It is also more operationally complex, which is why many teams deployed the Docker runner instead. If you are still running the Docker runner in a multi-tenant environment, migrating to the Kubernetes runner is the highest-leverage security change available to you.
The SSH and Exec runners run pipeline steps directly on the host without container isolation. They exist for specific use cases like building for macOS or Windows where container runners are impractical, but they offer no isolation at all between pipelines. Treat any pipeline running on an SSH or Exec runner as running with the full permissions of the host's user account, because that is the actual security model.
Secret handling and the plugin permission flag
Drone's secret model is based on named secrets attached to repositories or organizations, injected into pipeline steps that request them. A step declares its secret dependencies in the environment block of the YAML, and the runner binds the secret values into the container's environment at startup.
The critical security flag is pull_request: false on each secret. By default, Drone does not expose secrets to pull-request builds, to prevent a malicious PR from exfiltrating secrets. This is a correct default, but it is possible to override it per-secret, and once overridden, every future PR build against that repository has access to the secret. CVE-2022-31109 was not quite this, but it was close: a bug in the PR gating logic that allowed secrets to be exposed to PR builds in specific trigger configurations.
The hardening advice is to audit every secret with pull_request: true in every repository, and challenge each one. There is almost never a good reason to expose production credentials to arbitrary external contributors' pull requests, and the alternatives — running a separate deployment pipeline that triggers on merge to main — are usually straightforward.
The other flag to audit is the plugin permission on pipeline steps. Drone has a concept of trusted plugins that can use privileged Docker options like host mounts or capabilities. A step that sets trusted: true can bypass the normal container isolation, and any repository admin can set this flag. In a multi-tenant deployment, this is a de facto privilege escalation from repository admin to Docker host root. The Drone server has an administrator-only flag that disables trusted mode globally, and that is the right default for any shared deployment.
The plugin ecosystem and its CVE history
Drone plugins are container images that implement specific pipeline steps — publishing artifacts, running tests, deploying to a platform. The plugin ecosystem is large and of variable quality. The drone-plugins organization on Docker Hub hosts official plugins, but third-party plugins are common and are generally not audited.
The plugin supply chain is the weakest link in many Drone deployments. A plugin that is pinned to plugins/docker:latest will pull a new image on every build, and a compromise of the upstream plugin image is an immediate compromise of every pipeline that uses it. The hardening step is to pin every plugin to a specific digest, mirror trusted plugins into your own registry, and review plugin updates on a schedule rather than floating to latest.
A specific pattern to watch for: the drone-kubernetes plugin and similar deploy plugins often accept a kubeconfig as a secret and run kubectl apply with it. A malicious plugin version could exfiltrate that kubeconfig and gain direct access to your production clusters. The mitigation is to use short-lived credentials for kubeconfig generation and to prefer native Kubernetes service account authentication over long-lived kubeconfig secrets.
The server-to-runner trust model
The Drone server communicates with runners over an authenticated RPC channel protected by a shared secret. The secret is configured in the server's environment as DRONE_RPC_SECRET and in each runner's environment as the same value. If this secret is leaked, an attacker can register a rogue runner, receive build jobs, and exfiltrate the secrets those builds use.
Two things matter for hardening. First, the RPC secret should be rotated on a schedule — at least quarterly for production deployments — and the rotation process should be documented because it requires coordinated restart of the server and every runner. Second, the server's runner registration endpoint should be restricted to the IP ranges of your runner hosts using a firewall rule or a load balancer ACL. There is no reason for the runner registration endpoint to be reachable from the public internet in most deployments, and internet scanning regularly finds exposed Drone servers.
OSS end-of-life and the Harness transition
The OSS Drone CI project has not received a meaningful security update since Harness stopped active maintenance in late 2023. Critical CVEs in dependencies of Drone server and runner have been patched unevenly, and the project's maintenance status is best described as community-driven at this point.
If you are running Drone OSS in production, you have two realistic paths. The first is to migrate to Harness CI, which is the direct commercial successor and which gets active security maintenance. The second is to migrate to a different CI system entirely — GitHub Actions, GitLab CI, or Tekton are all reasonable targets depending on your environment. Staying on Drone OSS indefinitely is a growing risk as dependency CVEs accumulate without upstream fixes.
Whichever path you choose, plan the migration on a timeline that does not involve running Drone OSS for years longer. The specific CVE window that concerns me is Go's HTTP/2 implementation, which has had multiple DoS and request-smuggling CVEs over the past 18 months, and Drone server's HTTP handling inherits those vulnerabilities. Without active upstream maintenance, those fixes do not flow into the OSS releases.
How Safeguard Helps
Safeguard integrates with Drone CI deployments by ingesting the pipeline YAML across every repository, flagging steps that use floating plugin tags or set the trusted flag, and correlating the installed runner versions against the current CVE feed. The platform also tracks secret usage patterns across pipelines, alerts when a secret is exposed to pull-request builds, and provides an auditable record of which repositories have migrated away from Drone OSS and which remain. Combined with policy gates on the artifacts Drone produces, Safeguard gives you a continuous view of whether your Drone estate is operating to the hardening standards in this guide, which matters especially for the long tail of OSS installations that are no longer receiving upstream updates.