Skip to content
Back to blog
CI/CD

Securing Jenkins Pipelines

Jenkins-specific hardening steps — credential storage, plugin risk, agent isolation, and script approval — for teams still running self-managed CI.

S
SecureScout Team· Security Engineering
May 21, 20266 min read

Jenkins' flexibility — plugins for nearly everything, a full scripting language for pipeline logic — is also what makes it require more deliberate hardening than fully-managed CI platforms handle for you by default.

Credential storage

Use the built-in Credentials plugin rather than hardcoding secrets directly in pipeline scripts (Jenkinsfiles), which are typically stored in source control and visible to anyone with repository access. For higher-sensitivity credentials, consider integrating an external secret manager rather than relying solely on Jenkins' internal credential store.

Plugin risk

Jenkins' plugin ecosystem is large and not uniformly maintained — some plugins have a history of serious vulnerabilities, and outdated plugins are a common source of exploitable weaknesses. Keep plugins updated on a regular cadence, and audit which plugins are actually in use versus installed and forgotten.

Restrict script approval

Jenkins' "Script Security" plugin requires administrator approval for potentially dangerous Groovy script constructs used in pipelines. Don't disable this restriction for convenience — it exists specifically to prevent a pipeline script (which could originate from a pull request in some configurations) from executing arbitrary code with Jenkins' full permissions.

Isolate build agents appropriately

Jenkins agents (the machines actually executing pipeline steps) should be isolated based on trust level, similar to self-hosted CI runners generally — don't run jobs building untrusted, external contributions on the same agent pool as jobs with access to production credentials.

Restrict network exposure

Jenkins' web interface has had a number of disclosed vulnerabilities over the years, and it typically has significant access to build infrastructure and stored credentials. Avoid exposing it directly to the public internet; place it behind a VPN or restricted internal network access instead.

Enforce role-based access control

Jenkins' default authorization model can be permissive. Configure role-based access control so users and pipeline jobs have only the permissions they actually need — not broad administrative access by default.

Audit and update regularly

Jenkins itself receives regular security updates. Treat keeping Jenkins core and its plugins current with the same priority as patching any other piece of infrastructure with broad access to your build and deployment process.

jenkinsci-cdpipeline-security

Frequently Asked Questions

Is the Jenkins Credentials plugin sufficient for storing all secrets?

It's a reasonable built-in option and better than hardcoding secrets in pipeline scripts, but it lacks the audit granularity, dynamic secrets, and fine-grained access policies of a dedicated secret manager — consider integrating one for high-sensitivity credentials.

Should Jenkins be exposed directly to the internet?

Generally no. Jenkins' web interface and API have a history of vulnerabilities, and it typically has broad access to build infrastructure and credentials — placing it behind a VPN or restricted network access significantly reduces attack surface.

Related Articles

S

SecureScout Team

Security Engineering

Learn more →