What is Jenkins?
Jenkins is a powerful, open-source CI/CD tool that has become the defacto for software development projects due to its automated approach, Java-based infrastructure, and enormous plugin community. It accelerates software development by automating the end-to-end cycle including build, test, and deployment. Jenkins allows you to continuously improve the application and release fresh builds at speed. Its plugin ecosystem accommodates CI/CD by integrating your pipeline with any tool you wish including Git, Amazon EC2, and HTML publisher.
To clearly understand the importance of Jenkins, let’s quickly learn what continuous integration (CI) means.
In this article:
- What is CI?
- Why Use Jenkins for CI?
- How Secure is Jenkins?
- What is Jenkins Security Advisory and what does it do?
- What are the vulnerable Jenkins plugins?
- What are the must-follow Jenkins security best practices?
What is CI?
Continuous Integration (CI) is a software development practice that requires you to regularly commit changes to the source code in the central repository. It will then be automated for builds and tests. This approach helps you in detecting any flaws in the code, thereby allowing you to rectify the problems early. This accelerates the entire software development process enabling you to release quality applications.
Why Use Jenkins for CI?
Before Jenkins, you had to test the complete code before identifying the bugs and fixing them. Since developers work independently on different aspects of the project, coordination becomes a tedious and time-consuming process. This slowed down the software delivery.
In brief, the below steps show how Jenkins architecture works:
- Changes are committed to source code hosted in the repository.
- Jenkins CI server pulls the most recent update in the code
- An executable file is developed by the Build Server
- In case it fails, feedback is sent
- Build application is deployed to the test server
- The developer is alerted in case of a failure
- The tested application is deployed on the production server
How Secure is Jenkins?
Installing and getting started with Jenkins is a fairly easy process. However, having it securely configured takes a lot of planning with many factors at play. Primarily because Jenkins interacts with multiple servers and components, security becomes crucial. Moreover, with the kind of plugin dependency, Jenkins has, setting up a basic authentication mechanism won’t cut it.
In addition to offering capabilities to secure your system, Jenkins constantly reviews and updates plugin vulnerabilities through a process called Security Advisory.
What is Jenkins Security Advisory and what does it do?
Jenkins Security Advisory is a list of security issues identified and highlighted in Jenkins and plugins released periodically. The publication includes vulnerability description, security risks it poses, severities, vulnerable versions, workarounds, and resolutions if any.
Vulnerable Jenkins plugins
Below are five of the vulnerable Jenkins plugins mentioned in its 2022 security advisory list, their impact, and how they can be fixed.
- Active Directory Plugin – Transmits user credentials in plain text
Attackers can extract user credentials by capturing traffic between the Jenkins controller and Active Directory. This occurs because the Active Directory plugin transmits data without any encryption, exposing not just the credentials but also the Active Directory user.
Fix: To resolve the vulnerability, update to version 2.25.1
- Badge Plugin – Vulnerable to XSS attacks
Badge Plugin of version 1.9 and earlier allowed users to customize descriptions by adding URLs. However, it doesn’t follow the protocol for allowing arbitrary HTML links to open up the system for XSS attacks.
Fix: To resolve the vulnerability, update to version 1.9.1
- Bitbucket Branch Source Plugin – Allows capturing credentials
Bitbucket Branch Source Plugin can expose your credentials triggering disastrous CSRF attacks as it doesn’t require POST requests for an HTTP endpoint. Also, the Plugin does not check required permissions in many HTTP endpoints. This could lead to credentials capture and enumerating credentials IDs.
Fix: To resolve the vulnerability, update to version 746.v350d2781c184
- Conjur Secrets Plugin – Allows credential retrieval and secret decryption
Conjur Secrets Plugin allows agent processes to obtain all user credentials stored in Jenkins, and decrypt any attacker secrets. This gives a way for attackers to exploit agent processes to not just retrieve sensitive data but also obtain the plain text of encrypted secrets in Jenkins.
Fix: No resolution is available at this point
- Jenkins Matrix Based Security – Opens Jenkins for XSS attacks
Matrix Project Plugin allows storage of XSS vulnerability in your system by allowing risky HTML metacharacters in nodes and descriptions. With appropriate permissions, the vulnerability can be exploited for serious repercussions.
Fix: To resolve the vulnerability, update to version 1.20
Jenkins security best practices
Jenkins offers a variety of security features some of which are enabled by default, while others need to be configured based on the environment. Let’s take a look at the options you have to secure your Jenkins pipeline.
- Access Control
Jenkins undertakes a two-pronged approach to secure your pipeline from unwanted and unauthorized access.
- Security Realm
To authenticate a user, Jenkins uses a user database to determine users, their passwords, and the groups they belong to. Jenkins Own User Database has now been made the default security realm configuration for users to avoid trespassing.
Another option Jenkins allows for proper user authentication is using a third-party identity provider like LDAP (Lightweight Directory Access Protocol).
- Authorization
You can configure your Jenkins in a detailed manner by defining which user or group can access which sections of Jenkins. The authorization options that Jenkins offer are as follows:
- Anyone can do anything
With this option, everyone including anonymous users gets access to a complete play area as the name suggests. However, it isn’t a very good idea to pick this.
- Legacy mode
Only admins get full control over the system, while others will only have read access. Jenkins best practices advise you not to use this setting.
- Logged-in users can do anything
This setting forces users to log in before accessing any aspect of Jenkins. It also records actions every user takes within the system. You can also utilize advanced settings to give just read access to anonymous users.
- Matrix-based security
With this setting, you can establish controls in a fine-grained manner on which users and groups get what rights and access across the system.
- Project-based Matrix Authorization Strategy
An extension of Matrix-based security can be achieved by using the Matrix Authorization Strategy plugin. This allows you to set ProjectWise access control lists.
- Controller Isolation
In a Jenkins environment, code authors, build script authors and other users possess control over commands executed during the build. This approach exposes the system to external threats like supply chain vulnerabilities. To mitigate this and maintain the stability of the Jenkins controller, it is recommended that builds should not be executed on the built-in node. This distributed builds approach secures your environment from malicious attacks.
- Sanitizing Environment Variables
Environment variables come with potential risks and can harm builds, changing the behavior of the scripts. It is important to adopt processes that sanitize environment variables, blocking the unsafe variables containing insecure metacharacters like ^ and &.
Jenkins allows you to use the below plugins to filter the environment variables:
- Safe Batch Environment Filter – It automatically fails Batch build steps in case it identifies variables with Batch metacharacters
- Generic Build Step Environment Filters – Filters environment variables through standard implementations
- Pipeline: Keep Environment Step – Detects unused environment variables in pipelines
- Access Control for Builds
Jenkins recommends setting authorization to run builds within the system. By default, users that have access to execute builds also have authority to create, modify or delete other builds as well. Instead, you can use plugins like Authorize Project Plugin to set up ProjectWise build authorization.
- Protection against CSRF
Cross-Site Request Forgery is a security threat wherein an authenticated user is tricked into triggering an unwarranted action in Jenkins. It usually occurs when a Jenkins user visits a hostile website or clicks on a malicious link.
Jenkins safeguards your pipeline from CSRF attacks by generating a token called crumb for every user. The crumb contains specific user information for efficient identification. Whenever there is a request generated seeking any kind of modification, the system asks for the crumb.
- Avoid XSS Attacks
To help users steer clear of attacks like XSS (Cross-Site Scripting), Jenkins provides a functionality called Markup Formatter. This feature filters descriptions that users submit for a variety of purposes like user profiles, jobs, and builds to detect unsafe HTML metacharacters.
You can use OWASP Markup Formatter to sanitize HTML sources that users add in the descriptions.
Aqua can be your ideal Jenkins security partner
Despite its popularity and wide adoption, Jenkins is a platform that is vulnerable to security threats via multiple sources – Jenkins Controller, application code, XSS, and CSRF. The platform does offer an extensive infrastructure of plugins to secure your pipeline. However, keeping track of all the plugins and the added vulnerabilities they bring into the picture can be a task. Instead, you can delegate your security checks to an expert like Aqua’s policy-based solution. It is a one-of-a-kind security solution that protects your entire CI/CD pipeline through fine-grained access controls and continuous scanning.
You can view a demo of Aqua’s solution today to know how it can help secure your Jenkins-based supply chain.
