Woodpecker CI is the community fork of Drone that emerged when the OSS Drone project went quiet after the Harness acquisition. It is a small, self-hosted, container-native CI system with an active maintainer community, a growing user base among homelab operators and small teams, and an increasing presence in production environments where operators want a Drone-compatible system that still receives updates. For a security reviewer, the question is whether Woodpecker has addressed the inherited security debt from Drone and whether its trust model holds up in production.
This review covers Woodpecker CI as it stands in release 2.7 and 3.0, the current versions at the time of writing. The 3.0 release was a significant milestone — it broke some backward compatibility with Drone and cleaned up several security surfaces that had been awkward in the 2.x line. The review focuses on runner isolation, secret handling, the plugin ecosystem, and the operational security surface.
What changed from Drone
Woodpecker started as a near-drop-in fork of Drone v1, and the 2.x releases maintained broad compatibility with Drone pipeline YAML. The 3.0 release broke compatibility in some areas to address design issues that Drone had inherited from its early days. Specifically, the 3.0 release removed the trusted-mode flag from repository settings in favor of per-workflow trusted settings, tightened the secret exposure rules for pull-request builds, and reworked the agent protocol to use gRPC with stronger authentication.
The 3.0 changes are not purely additive — organizations migrating from Drone or from Woodpecker 2.x need to review their pipeline configurations. The migration is straightforward for most pipelines but it will surface configurations that depended on the old loose defaults, which is useful because those are exactly the configurations that should be reviewed for security issues anyway.
The project has also been responsive to security reports. The advisories page on the Woodpecker repository shows a reasonable cadence of disclosed and patched issues, with most critical issues patched within a week of disclosure. This is not enterprise-grade security response, but it is meaningfully better than unmaintained Drone OSS, and it is sufficient for most self-hosted use cases.
The runner model and isolation
Woodpecker's runner model is inherited from Drone: pipeline steps run as containers, and the available runner types are Docker, Kubernetes, SSH, Exec, and a Local runner for development. The security characteristics of each are the same as in Drone — Docker and Kubernetes offer container-level isolation, SSH and Exec offer no isolation, and Local is for development only.
The hardening pattern is the same as for Drone. For multi-tenant environments, use the Kubernetes runner with per-pipeline namespaces and RBAC that restricts what each namespace can do. For single-tenant environments where all pipelines belong to the same team, the Docker runner is acceptable if you pin step images and audit pipeline configurations. The SSH and Exec runners should be treated as full host access and used only for specific needs where container isolation is impractical.
A specific Woodpecker-only consideration is the backend abstraction layer. The 3.0 release refactored the runner's execution backend into a pluggable interface, which is elegant from a software design perspective and introduces a new attack surface — the backend interface itself. A bug in the backend dispatcher could theoretically route a step to a less-restricted backend than the pipeline intended. No such bug has been reported as of this writing, but it is a surface worth knowing about.
Secrets and the pull-request gate
Woodpecker's secret model is repository-scoped with per-secret flags controlling which events can access the secret. The flags are push, tag, pull_request, deployment, and cron. The default for new secrets is to expose them to push and tag events but not to pull_request events, which is the right default.
The pattern to audit is the pull_request: true flag on secrets. In a repository that accepts external contributions, a secret exposed to PR builds is a credential that any contributor can extract by opening a PR that exfiltrates it. The Woodpecker documentation is clear about this risk, but the mechanism is easy to enable without fully understanding the implications.
The 3.0 release tightened the secret exposure rules further by requiring that secrets exposed to PR builds be explicitly flagged as "plugin-only," meaning they can only be used within plugin steps and not in freeform shell commands. This is a useful constraint that prevents the most common exfiltration pattern where a PR modifies a shell command to read and send the secret. Whether the constraint is bypassable through specific plugin behaviors is an area worth testing in a production-critical deployment.
The plugin ecosystem
Woodpecker plugins are container images, like Drone plugins, and the plugin ecosystem has meaningful overlap with Drone's. Most Drone plugins work unchanged in Woodpecker 2.x. The 3.0 release introduced a Woodpecker-specific plugin metadata format that allows plugins to declare their required permissions, which is a useful hardening feature that is not yet widely adopted.
The security advice is the same as for Drone. Pin plugin images to digest references, mirror trusted plugins into your own registry, and review plugin updates on a schedule. For plugins that are not widely used or that are maintained by individual developers, consider replacing them with a custom implementation or a different approach — the plugin is a trust boundary and a small-audience plugin is a plausible supply chain risk.
Woodpecker has a curated list of plugins that are officially recommended, distinguished from the broader ecosystem. Sticking to the recommended set is the conservative starting point. For any plugin outside the curated list, the plugin source code should be reviewed at least once before adoption, and updates should be reviewed rather than auto-accepted.
The server and its operational surface
The Woodpecker server is a Go binary that serves the web UI, accepts webhooks from git forges, dispatches builds to agents, and stores build metadata in a database. It runs typically as a single container with a persistent volume for the database, or with an external database for larger installations.
The server's attack surface includes the webhook endpoints (which must be reachable from your git forge), the UI and API endpoints (reachable from users), and the agent RPC endpoint (reachable from agents). Each of these should be exposed only as narrowly as operationally necessary.
A common misconfiguration is exposing the agent RPC endpoint to the public internet. The endpoint is authenticated by a shared secret, but exposing it publicly is unnecessary for any installation where agents run in known network locations. Restrict the RPC endpoint to the IP ranges of your agent hosts, either through a firewall rule or by deploying the agents on the same private network as the server.
The webhook endpoints do need to be reachable from your git forge, and the correct hardening is to restrict them to the known webhook IP ranges of the forge. GitHub, GitLab, Gitea, and others publish their webhook IP ranges and those should be configured in your firewall. This cuts off the internet-scanning attack surface while still allowing legitimate webhook delivery.
The community maintenance model
Woodpecker is maintained by a small group of volunteers with occasional corporate contributions. The security response has been reasonable, but the project does not have the resources of a commercial vendor, and response times for low-priority issues are measured in weeks rather than days.
The operational implication is that Woodpecker is a good choice for environments where you have security response capacity of your own — where you read advisories, test patches, and deploy updates on a schedule that suits your risk tolerance. For environments where you need vendor-backed security response, a commercial CI platform is a better fit. The reasonable middle ground is to use Woodpecker for non-critical pipelines and a commercial platform for pipelines that produce production-deployed artifacts, which is what many organizations that use Woodpecker actually do.
How Safeguard Helps
Safeguard integrates with Woodpecker CI by ingesting the pipeline YAML across your organization, flagging steps that use unpinned plugin images or secrets with pull_request: true, and correlating the installed Woodpecker version against the current advisory feed. The platform also tracks the artifacts Woodpecker produces and validates their provenance attestations against your policy gates. Combined with continuous monitoring of agent configurations and alerting on server misconfigurations, Safeguard gives you an auditable view of whether your Woodpecker estate is operating to the hardening standards in this guide, which matters especially for the community-maintained installations that do not have dedicated security response resources of their own.