Jenkins shared libraries are safe only if you control who can change them. Trusted libraries run outside the Groovy sandbox and can call any method, so anyone who can push to that repository could obtain unlimited access to Jenkins. Untrusted libraries run in the sandbox like ordinary Pipeline code.
Trusted versus untrusted
| Trusted | Untrusted | |
|---|---|---|
| Sandbox | Not sandboxed | Groovy sandbox applies |
| Can call | Any Java, Groovy, Jenkins internal or plugin method | Only what the sandbox allows |
| Who configures | Needs Overall/RunScripts, usually admins | Overall/Manage |
| Replay | Not supported | Supported for testing changes |
Folder level libraries are always untrusted. The Jenkins documentation warns about trusted repositories directly: "anyone able to push commits to this SCM repository could obtain unlimited access to Jenkins." Treat push access to them like admin access.
Pin versions
Each library can have a default version, which can be a branch, tag or commit hash. Production should use tags or commit hashes, since a branch can move under you.
- If "Allow default version to be overridden" is on, a Pipeline can pick another version with an annotation.
- If it is off, scripts cannot override the default.
- With no default, every Pipeline must name a version.
- A replayed build reuses the exact revision of the original, even if a branch was requested.
Implicit loading
A library marked "Load implicitly" is available to every Pipeline with no annotation. That makes it convenient and also wide in reach, so only mark a library implicit when every job really needs it.
Hardening steps
- List your global libraries and mark which are trusted.
- Restrict push and merge rights on trusted repositories, and require review.
- Keep trusted code small. Wrap unsafe calls in narrow functions that Pipelines can use safely.
- Avoid
@Grabin trusted libraries. The docs suggest a standalone executable installed on agents and called through a shell step. - Pin to tags or commit hashes in production.
- Do not keep state in global variables, since shared state can be lost on controller restart.
A note on caching rules: "Versions to exclude" always takes precedence over "Versions to include."
Try it yourself
The demo shows a pull request gate, the control that should sit in front of any library repository.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard applies policies and gates on pull requests, which helps enforce review of changes to pipeline code. Start with the free scan.
Quick check
Why are trusted libraries risky?
They are not sandboxed, so whoever can push to the repository can run arbitrary code with Jenkins level access.
Should I pin to a branch?
For production, use a tag or commit hash. Branches move, which hurts reproducibility and review.
Sources
Last reviewed: 19 October 2026.
