Harden Jenkins in five moves: keep anonymous access off, run builds on agents with the built-in node at 0 executors, leave agent to controller access control on, scope credentials tightly, and keep Groovy sandboxed with admin-reviewed approvals. Each move comes from the official Jenkins documentation.
The checklist
| Control | What to check | Where it comes from |
|---|---|---|
| Access | Anonymous access is off and admins are few | Jenkins does not allow anonymous access by default, but a disabled setup wizard may not set this |
| CSRF protection | Still enabled | On by default |
| Built-in node | Executors set to 0 | Controller isolation guidance |
| Agent to controller access control | Not disabled | Always on since Jenkins 2.326 |
| Credentials | Scoped to folders or jobs, bound with IDs | Credentials documentation |
| Groovy | Sandbox on, approvals reviewed | Script Security plugin |
Step by step
- Confirm authentication. Open Manage Jenkins and check the security settings. If you disabled the setup wizard at install time, verify access control yourself, since the wizard is what configures it securely.
- Move builds off the controller. Add agents, then set the built-in node to 0 executors.
- Review who can edit jobs. Job/Configure holders can run arbitrary steps. Treat them as less trusted than admins.
- Audit credentials. Remove ones nobody uses. Prefer scoped credentials bound with the credentials() helper or withCredentials, with single-quoted shell steps.
- Check the approval queue. Look at the In-process Script Approval page and reject anything you do not recognise. Consider forcing the sandbox globally on a locked-down instance.
- Update. Apply Jenkins core and plugin updates on a schedule. Plugins are code that runs inside the controller.
What this checklist leaves out
It does not cover network placement, backups, or TLS in front of Jenkins, all of which matter and depend on your environment. It also does not protect the code your jobs build. A hardened controller can still ship a vulnerable dependency, which is why a scan step belongs in the pipeline.
Common mistakes
- Treating the setup wizard as optional and never revisiting access control afterward.
- Giving every developer Job/Configure on every folder, which lets any of them run commands on an agent.
- Leaving one shared credential with broad reach because splitting it felt like work.
- Skipping plugin updates because a job might break, then running a plugin with a known flaw for months.
- Approving scripts in the approval queue without reading them, to unblock a colleague.
A good rhythm is monthly for updates and approval queue review, and quarterly for credentials and user permissions. Put those dates in a calendar, not in someone's memory.
Quick check
Which single change helps most?
Moving builds off the controller. It separates job authors from the host that stores your credentials.
How often should I review credentials?
On a schedule you can keep, such as quarterly, and immediately after anyone with job access leaves.
Safeguard adds dependency scanning, SBOM generation and pull request gates around a pipeline like this. The free scan is a quick way to see your current dependency exposure.
Sources
- Jenkins: Security overview
- Jenkins: Controller Isolation
- Jenkins: Using credentials
- Jenkins Script Security plugin
Last reviewed: 19 October 2026.
