Jenkins is one of the most well-known tools for creating automation pipelines and integrating them with the rest of your CI/CD tools. It has an active community that has contributed thousands of plugins to extend its core functionality, which is why it is the industry standard for creating build, test, and deployment processes.
Jenkins can connect and automate many organizations’ SDLC processes across their cloud and on-premise infrastructure by utilizing many of its plugins. However, it could also become your organization’s weakness without proper controls. Besides the obvious supply chain threats like the SolarWinds hack, a compromised system can threaten the entire production environment and be an entry point for inserting malicious software and exfiltrating sensitive data.
Part of Cycode’s role as a leader of supply chain security is securing these types of build systems. This article shares our real-life experience of applying Jenkins security best practices to avoid the mentioned risks and maintain strong ASPM practices.
Key Takeaways:
- Jenkins is a powerful but high-risk CI/CD tool—without proper controls, misconfigurations, outdated plugins, or excessive permissions can expose your entire software supply chain.
- Strengthening Jenkins security helps detect issues early, protect sensitive data, support compliance, and ensure a resilient, trustworthy pipeline.
- Following Jenkins security best practices—like isolating the controller, using role-based access, hardening credentials, and containerizing builds—significantly reduces your attack surface.
Why Jenkins Security Is Critical for Developers
Jenkins remains a foundational tool in the CI/CD ecosystem, but its widespread adoption and plugin-driven extensibility also make it a prime target for threat actors. In fact, nearly half (44%) of developers use Jenkins, making it one of the most widely used CI tools in the world.
Because Jenkins pipelines are often deeply integrated into critical software delivery processes, a single misconfiguration or overlooked vulnerability can compromise the entire build environment.
For developers, Jenkins security isn’t just an Ops or Security concern…it’s a shared responsibility. Developers define pipeline logic, manage secrets, and control access to SCM and cloud environments. Without guardrails in place, even a small oversight in a Jenkinsfile can open the door to credential leaks, code tampering, or lateral movement across systems.
In an era of growing supply chain attacks, strengthening Jenkins security is one of the most impactful ways for developers to shift security left—catching issues early and safeguarding the integrity of every commit and release.
Benefits of Strong Jenkins Pipeline Security
Strengthening Jenkins security isn’t just about preventing breaches. It delivers real value across the SDLC and development teams. A secure, resilient Jenkins setup ensures your pipelines remain trustworthy, efficient, and protected against evolving threats. Key benefits include:
- Early Detection of Security Risks: Secure Jenkins configurations help detect vulnerable dependencies, risky plugin behavior, and misconfigured pipelines before they reach production.
- Protection of Sensitive Information: Hardening credential storage and access policies prevents secrets from leaking into logs, artifacts, or compromised containers.
- Compliance with Industry Standards: Enforcing best practices in Jenkins supports compliance initiatives like SSDF, SLSA, NIST 800-53, and internal audit requirements.
- Enhanced Collaboration and Efficiency: Role-based access and controlled environments give developers the autonomy to work safely without compromising system integrity.
- Reduced Attack Surface: Disabling unused ports, plugins, and executor configurations helps limit entry points for attackers and bots.
Improved Reliability and Trust: Teams and stakeholders can trust that pipeline executions are secure, consistent, and free from tampering—boosting confidence in release quality.
Best Practices for Securing Jenkins
To help teams reduce risk and protect their build environments, we’ve compiled a list of proven Jenkins security best practices. These recommendations are based on real-world experience securing pipelines at scale and are designed to help you harden Jenkins against misconfigurations, plugin vulnerabilities, and broader supply chain threats.
Core and Outdated Plugin Updates
When searching for known vulnerabilities, we can split Jenkins into two components: core automation platform and plugins, which come on top. According to CVE Details, since Jenkins launched in 2011, almost a thousand vulnerabilities have been reported, and the majority are from the past three years:
Note – As you will see below, we suggest installing several popular plugins that add to Jenkins’s security controls. Even though the recommended plugins are popular with thousands of downloads, it is vital to maintain and update them as they may contain vulnerabilities requiring patching.
Keeping a vulnerable version is extremely risky because malicious actors could exploit your server using publicly available exploits. While updating a core version is a manual process, updating plugins is straightforward and done through a few clicks on Jenkins UI. Most of the published vulnerabilities are plugin-related; thus, the latter will close most security issues.
Operating System Hardening
Even the most hardened Jenkins application won’t help if installed on a non-secure server or in a non-secure manner. Most Jenkins servers will probably be Linux-based, so we would suggest applying general Linux recommendations to deny malicious access and modification to the server, such as:
- Verify that only needed ports are opened (such as HTTP). If you need additional protocols, such as SSH, define proper firewall rules to block unnecessary access.
- Run Jenkins as a non-administrator user.
- Harden permissions for the JENKINS_HOME directory only for the proper Jenkins user.
- Verify that the Jenkins user cannot elevate his permissions through the sudo command. You can do this by modifying the /etc/sudoers file.
- Configure Jenkins with HTTPS protocols and trusted certificates.
- Due to its sensitivity, consider blocking your Jenkins server from public access by either installing it in the on-premise network or through a tight security group policy.
The rule is simple – secure the server as much as you secure your Jenkins application.
Authentication
Jenkins supplies several built-in authentication methods (these are also called “Security Realms” in Jenkins) – “Delegate to servlet container” and “Jenkins’ user database”. For the best Jenkins security settings, do not use the built-in methods and instead use a centralized thirdparty vendor to authenticate against, such as GitLab, Github, LDAP, SAML, and Google. By utilizing these methods, specific policies could be applied to the passwords, like password complexity, which helps deny malicious access to the server.
If you did choose “Jenkins’ user database” as a temporary solution, we suggest disabling the “Allow users to sign up” option and manually controlling the registered users.
Authorization
Similar to the previous section, Jenkins supplies the following built-in authorization methods: “Anyone can do anything,” “Legacy mode,” and “Logged-in users can do anything.” We suggest not using these built-in methods but using plugins for more advanced authorization methods.
The most recognized plugins for this purpose are Matrix Authorization Strategy and Role-based Authorization Strategy, which allow great flexibility for implementing PoLP (Principle of least privilege) by defining the privileges of anonymous, authenticated, or specific users. In addition, you can also define privileges per project or assign created roles for each user. This tutorial by Thetips4you explains the process of defining roles through these plugins.
Using GitHub-based and GitLab-based authorization is also possible (using previously mentioned plugins). Still, we discourage that due to the lack of granularity of permission definition and possible misconfiguration.
Security (Mis)configurations
The Jenkins-managed architecture comprises a controller server with build configurations, encrypted secrets, and agents that run the builds. To enable Jenkins best practices, you should protect the controller node by denying or limiting any code execution.
By default, Jenkins gives the controller node broad access and permissions—which makes it a high-value target. Any scripts or builds running on the controller can interact with the Jenkins filesystem, configuration files, secrets, and more. This makes misconfigurations on the controller especially dangerous, as they could expose sensitive data or allow an attacker to pivot further into your environment.
Securing Jenkins starts with reducing the controller’s responsibilities. Treat it as an orchestrator, not an executor. Avoid installing unnecessary tools or plugins directly on the controller, and ensure that build workloads are delegated to isolated agents with tightly scoped permissions. Combined with proper network segmentation, this limits the blast radius of any potential compromise.
No Executors on the Controller Node
Pipelines run on the controller node have direct access to the Jenkins filesystem, the configured workspace, encrypted secrets, and additional assets. Running builds on the controller node is extremely risky and should be disabled. You can do this by going to “Manage Jenkins” → ”Manage Nodes and Clouds” → ”Built-In Node” → ”Configure” → setting “Number of executors” to 0.
Hardening Inbound Connections
The default agent-to-controller communication is done by agents initiating TCP connections to the controller through a dedicated port. This method is called an inbound agent.
If you are not using this method, the inbound port on the controller node should be completely disabled. If your environment requires inbound connections, it is crucial to ensure the connections are encrypted. Jenkins offers a setting called “Inbound TCP Agent Protocol/4 (TLS encryption)” that should be turned on to run inbound connections through the secured TLS protocol.
These configurations can be found at “Manage Jenkins” → “Configure Global Security” → “Agents.”
Disabling SSHD
If the SSH Server plugin is installed, verify that SSH is turned off by configuring “Manage Jenkins” → “Configure Global Security” → “SSH Server” → “Disable.”
Limiting the Agent Permissions
By default, build pipelines will run with the internal SYSTEM user permissions. This strategy allows builds to run code on any node, create and delete jobs, start and cancel other builds, and more. Running builds with such permissions can cause serious security issues if, for example, Jenkins pulls malicious build pipelines from the SCM platform, which the Jenkins administrator doesn’t monitor. Here is an example of a default privileged build log showing the permissions at the second line:
By using the Authorize Project plugin, you can configure which user, hence what permissions, will run the build. The rule of thumb would be to set the least privilege for every project. Here is an example of the build log after modifying its permissions at “Manage Jenkins” → “Configure Global Security” → “Access Control for Builds” to have the same as the user who triggered the build.
Running Containerized Agents
There are many methods and guides for running the agents – physical machine, virtual machine, container, Kubernetes cluster, and more. From a security perspective, we want to minimize the impact of a compromised build over other builds or the entire system. Thus, we prefer that each build environment be created as a new container from scratch.
As explained in this article by The Xebia Engineering Blog, this could be done by creating a container image with all needed dependencies and deploying the job to a remote Docker service. Doing that will ensure that each build will run on a separate clean container.
The main drawback of the previous solution is that you need to create manually the agents who would run the containers. This presentation by Google Cloud Tech walks you step-by-step on how you can use the Kubernetes plugin to provision the agents dynamically, thus creating a complete ephemeral environment that depends solely on the SCM system. Example for such Jenkinsfile configuration:
pipeline {
agent {
kubernetes {
yaml '''
apiVersion: v1
kind: Pod
metadata:
labels:
some-label: some-label-value
spec:
containers:
- name: maven
image: maven:alpine
command:
- cat
tty: true
'''
}
}
stages {
stage('Run maven') {
steps {
container('maven') {
sh 'mvn -version'
}
}
}
}
}
Manual Plugin Installation
To ensure you follow the best practices for Jenkins security, install your plugins manually through the UI by uploading a *.hpi file. You can access this menu in the UI by going to “Manage Jenkins” → “Manage Plugins” → “Advanced” → “Deploy Plugin”:
We heavily discourage installing plugins outside the Jenkins plugin manager. Non-verified plugins could contain malicious behavior, and installing them could lead to security breaches and system compromise.
We suggest verifying the package’s source or downloading it from the official plugin repository if required.
Safe HTML Rendering
The default behavior in Jenkins is text rendering, meaning that all the descriptions are treated as text, and all HTML tags are escaped for XSS (Cross-site scripting) protection. You can also configure HTML rendering with the help of OWASP Markup Formatter, which implements an HTML subset without risky tags such as <script>. After installing this plugin, you should configure “Manage Jenkins” → “Configure Global Security” → “Markup Formatter” → “Safe HTML”.
Secure Credentials
The Jenkins core application doesn’t provide reasonable solutions for limiting credentials exposure for specific users and builds, but several popular plugins are doing that exceptionally.
Each added credential into Jenkins is defined either as “Global” (making it available for Jenkins, nodes, items, all child’s items, basically everything) or as “System,” which makes it available for Jenkins and nodes only. In addition, you can create “Domains” for credentials, which helps organize and access them.
Creating credentials in “Domains” doesn’t give any security benefits and leaves them with the same amount of exposure, meaning any build can access these credentials. For example, developers who modify and commit to a file in an SCM platform could exfiltrate sensitive secrets without accessing Jenkins. This article demonstrates some methods attackers could use to exploit this concept.
To counter this, we can use the popular Folders plugin to define credentials under specific folders, which would be accessed only by the pipelines under that folder. To use this feature, we will create a new folder (through “New Item” → “Folder”) or use an existing one, go to “Credentials” → “Folders,” and create our credentials there.
To complete it, we’ll also want to limit users from accessing these pipelines. For that, we can use the aforementioned Role-based Authorization plugin by creating authorization roles for that folder using regular expressions.
Audit Logs
Plugins like Audit Trail allow writing or sending logs to a remote server (Syslog server or Elastic Search). Enabling this feature allows the investigation of security incidents or the creation of anomaly rules to detect malicious activity and prevent breaches. After you install the plugin, you should go to “Manage Jenkins” → “Configure System” → “Audit Trail” and configure your desired logging method
Ensure Jenkins Best Practices with Cycode
Despite the popularity increase of SaaS-oriented workflow systems, such as GitHub Actions and GitLab Runner, our experience shows that Jenkins remains a leader in continuous integration software. With the rise of supply chain attacks in the past years, it has become an ideal target of choice for threat actors to reach the entire chain of software development, integration, and deployment.
By following Jenkins security best practices, you can stop attacks before they start. Appropriate controls need to be configured manually or through a third-party security platform like Cycode.
Book a demo to learn more about how Cycode can help secure your software supply chains.
