Drone CI, now part of the Harness platform, holds a distinctive niche: container-native, configuration-light, and popular with teams that want a CI system that gets out of the way. The simplicity is a real strength, but it can lull operators into skipping hardening work that the platform happily lets you defer. The defaults are reasonable for an experimental setup; they are not enough for a pipeline that signs production artifacts.
This guide walks through the controls that matter most in 2026, with a focus on the container-native patterns that Drone makes easy and the supply chain integrations that have stabilized over the last year. The work is mostly about discipline and explicit configuration, not novel tooling.
How do you manage plugin trust in Drone?
Drone's plugin model is its defining feature: every step in a pipeline is a container image, and any container image can act as a plugin. This is enormously flexible, but it means the supply chain risk for a pipeline collapses to the supply chain risk of the images it pulls. A pipeline that pulls plugin images from arbitrary Docker Hub publishers is taking on whatever trust posture those publishers happen to have.
The control that pays the most rent is a private registry mirror for plugin images. Pull through your own registry, restrict the upstream sources to a small allowlist of trusted publishers, drone-plugins itself, your own namespace, and a handful of vetted vendors, and pin every plugin reference in the pipeline to a content-addressable digest rather than a tag. Plugin authors who push image updates under the same tag will not silently affect your pipelines, and a compromise of a plugin's upstream image cannot reach your builds without the digest changing.
How should runners be isolated?
Drone runners come in several flavors, Docker, Kubernetes, Exec, SSH, and each has its own security profile. The Kubernetes runner with ephemeral pods is the safest production profile and should be the default for any installation that takes security seriously. The Docker runner is workable if the host is dedicated and runners are constrained with strong cgroup limits and a restrictive seccomp profile. The Exec and SSH runners run pipelines directly on the host without isolation and should be reserved for trusted internal automation only, never for builds triggered by external pull requests.
For the Kubernetes runner, configure pod security so that build containers run as non-root, with read-only root filesystems where possible, and with network policies that allow only the specific outbound destinations the build actually needs. The standard incident pattern in container-native CI is a build escape into the runner node followed by lateral movement; pod security and network policy are the two controls that break that chain.
How do trusted pipelines work?
Drone supports a trusted mode on pipelines that grants additional privileges, host volume mounts, privileged containers, network host mode, that are dangerous in untrusted hands. Configure repository settings so that trusted mode is off by default, and grant trusted mode only on repositories where it is necessary and where push access is tightly controlled.
Drone also supports pipeline signing via a server-side signature on the .drone.yml file, which prevents a pipeline file from being modified between commit and execution. Enable signing for any repository that runs in trusted mode or that has access to production credentials, and rotate the signing key on a schedule. The signature does not prevent an attacker who can push to the repository from changing the pipeline; it prevents tampering with the pipeline contents in transit or in the Drone database, which is a meaningful additional layer.
How should secrets be scoped?
Drone's secrets can be scoped at the repository, organization, or external secret manager level. The right default is to scope secrets to the repository and to use external secret managers, Vault, AWS Secrets Manager, GCP Secret Manager, for anything beyond trivial credentials. The external secret manager integration fetches secrets at pipeline run time using the runner's own credentials, so the secret never appears in the Drone database and can be rotated independently.
Additionally, mark secrets as restricted so that they are only available on pipelines triggered by pushes to protected branches, never on pull request pipelines from forks. The default behavior on fork PRs should be that secrets are unavailable, and any deviation from that default should require explicit configuration and explicit justification. The standard supply chain attack against Drone is a malicious fork PR that exfiltrates a credential through a pipeline step; restricted secrets break that attack cleanly.
How does Drone integrate with SLSA and sigstore?
Drone does not ship native SLSA provenance generation in the way that GitHub Actions or GitLab CI do, but the container-native model makes integration straightforward. Add a provenance-generation step at the end of the pipeline that captures the materials, the builder identity, and the artifact digest, signs it with cosign using the Drone OIDC token via Fulcio, and pushes the resulting attestation to the registry alongside the artifact.
The OIDC token support landed in Drone 2.20 and is now stable enough to use for both provenance signing and cloud credential exchange. Configure your registry, your cloud provider, and your attestation store to trust Drone as an OIDC issuer, and write trust policies that match on the specific repository and pipeline claims. The resulting artifacts are fully interoperable with the broader sigstore and SLSA ecosystem, and downstream consumers can verify them with slsa-verifier and cosign without knowing or caring that Drone produced them.
How Safeguard Helps
Safeguard ingests Drone-produced SLSA provenance and SBOMs alongside data from other CI systems, treating all of them as evidence in the same supply chain inventory. Griffin AI correlates Drone pipeline identity with artifact CVE findings and reachability, surfacing posture issues in plugin trust, runner isolation, and secret scope. Policy gates verify Drone-produced artifacts at deploy time with the same verification stack used for hosted CI, integrating cosign and slsa-verifier. TPRM scoring covers vendors who ship via Drone or Harness CI, factoring in their pipeline hygiene, and zero-CVE base images plug directly into Drone container-native flows for downstream consumers.