How to Secure Jenkins Pipelines without the hassle

Organizations spend countless hours and resources trying to effectively incorporate application security into their software development environments. Difficulty deploying and scaling security within modern development pipelines causes friction among teams throughout the software development life cycle (SDLC). Manual processes and workarounds have plagued the security landscape for decades. The need for constant scanning slows down release cycles and increases developer inefficiencies. And at the same time, 79% of organizations report that developers are under increasing pressure to shorten release cycles.

So the question remains, why are companies so adamant about including security into their value streams?

Why Application Security?

Security is essential at every layer of the software stack. Until recently, application security has been implemented at the peripheries to ensure that threats had no way to get into an application. The idea here being that if an attacker cannot gain access into an application using a peripheral control (such as an exposed network port), there is little damage that can be done to compromise the application and its users. This makes sense until you look at how the software stack actually works to deliver a product to a user.

Take a look at a simple web application below with the example of safeguarding networking ports.

Because ports are exposed to users, users are able to interact with the application. Information is passed between these ports so the application can respond with the desired output.

With a traditional application security model, teams would work together to ensure that all the necessary network ports are configured correctly to allow only connections that are deemed safe and secure. For these purposes, let’s say that “Port 8080” is a safe port and the only one to which an outside user has access.

From a networking perspective, there is only one way in and one way out. The team has successfully contained the application. Compliance reports and audits all point back to policies/rules created to ensure all the port networking components are mapped to their specified frameworks.

But what about the application layer itself? This approach to security doesn’t prevent attacks via methods such as SQL injection—where an attacker can hijack a session and pass a string (such as “or 1=1” added to a functioning query string), which enables malicious side effects within the application.

And what about modern application development using DevOps practices and the cloud? Today, software stacks plug into automated continuous integration/continuous delivery (CI/CD) pipelines that remove the usual overhead of getting software out to customers—and it’s the only way organizations can accelerate delivery to meet demand. While this automation drives the modern software factory, it also gives attackers a new way to compromise systems. So is there a way to secure these kinds of automated development workflows?

Developers need a way to ensure that the application layer and automation stack doesn’t compromise an organization from the inside out.

What’s Inside?

To show how easy it is to incorporate application security into the DevOps toolchain, we will deploy Contrast Assess into an existing declarative Jenkins pipeline. This provides the ability to incorporate real-time vulnerability analysis into the automation toolchain without doing much outside the current workflow.

We’ll need some things set up prior to deployment, including the following prerequisites:

• An existing Jenkins instance
• The ability to download plugins within Jenkins
• An existing declarative pipeline
• A Contrast Application Security Platform license
• A Contrast server

The assumption here is that the development team already has pipelines allocated to their respective applications, they are fully functional, and all necessary access has already been handled.

How it Works

Below is a high-level diagram of how the Contrast platform integrates with Jenkins.

Contrast/Jenkins integration allows users leverage the Contrast Application Security Platform by:

• Incorporating the Contrast security agent into the Jenkins workspace offers users the ability to use any of the solutions in the Contrast platform within any job/pipeline step
• Giving users the ability to create post-build steps/gates based on outcomes from vulnerabilities found in the application by the Contrast agent
  • These outcomes map to policies/rules found at system, job, and organization levels and determine whether or not a job fails
• Enabling users to manage and maintain policies/rules that map directly to:
  • A Jenkins system-level instance
  • A Jenkins job-level (e.g., development teams, pipelines, etc.)
  • The Contrast Security organization

The following demo will walk you through the Contrast/Jenkins joint solution in step-by-step detail.

Step #1: Confirming the Contrast Security Agent Connection Details

For the purposes of this demo, we will be using the Contrast Security Community Edition.

Start by logging into the Contrast Security Team Server to get some configuration information. Navigate to the user profile page—click on the top right dropdown and select User settings. Scroll down to the second half of the page where you will see a section labeled Keys. Make sure you have access to the following pieces of information:

• Organization ID
• Contrast Team Server URL
• Contrast Security Secret Key

You will be updating the Contrast Security plugin configuration within Jenkins with the above information.

Step #2: Setting up the necessary plugin

The next step is to download the necessary plugin. Navigate to your Jenkins UI and download the latest Contrast Security plugin from the Jenkins marketplace.

Select download now and install after restart from within the Jenkins UI and click import to make the Contrast plugin available to your Jenkins instance.

Now that you have access to the Contrast plugin, configure the plugin using the details from your Contrast Security Team Server (see Step #1) within the Jenkins UI Manage System Configurations view.

Here is a mapping of the required fields:

• Connection Name = Contrast Profile that will be used for all out-of-the-box Contrast plugin steps
• Contrast Username = Log-in credentials for your Contrast Security Team Server
• Contrast API Key = Found in User Profile Keys
• Contrast Service Key = Found in User Profile Keys
• Contrast URL = Found in User Profile Keys (NB: be sure to add ‘/api’ at the end of the Contrast URL. An error will flag if this is not provided.)
• Contrast Organization ID = Found in User Profile Keys

Make sure you can connect to your Contrast Security Team Server by testing the connection within the Jenkins UI. You will see a success message similar to the one below.

At this point, you’ve successfully connected to the Contrast Security Team Server. Now take a look at how policies fit into the picture.

Step #3: Creating some order with policies

Application policies/rules are a means to map security rules to objects. When the contrastVerification step runs within the pipeline job, vulnerabilities that are found by the agent during the job run will cross-reference these configurations and determine whether a job passes or fails—thereby acting as a gate. For this demo, we will only use the default, out-of-the-box policy/rule configurations.

With Contrast/Jenkins integration, policies are able to be set at various levels, which include:

• For Jenkins:
  • System-level policies (i.e., the entire Jenkins instance)
  • Job-level policies (i.e., individual development teams)
• For Contrast Security Team Server:
  • Organization-level policies

Having options at these levels is vital to ensure there is consistency across teams and flexibility among managing individual application pipelines.

Below is a sample configuration inside Jenkins for a Contrast Vulnerability Security Control:

In order to override settings at the job level, you need to update the “Allow job level application vulnerability security controls to override those controls defined here at the system level” configuration under Connection Details. Further reading on the subject is found here.

Now that you’ve connected to the Contrast Security Team Server and taken a look at both system and job-level policies, let’s “bootstrap” an existing pipeline with application security.

Step #4: Getting the pipeline in order

For the purposes of this demo, simply copy and paste declarative pipeline code from this GitHub repository—but you can just as easily create a pipeline job from an existing one via the Jenkins UI.

Start by navigating to the GitHub repository to obtain the pipeline code. It should look like the following: 

(NB: The petclinic application uses java jdk 8 and maven3 configurations to build and deploy.)

Run the pipeline to see the results by clicking “Build Now.” The pipeline should complete without error.

Clicking into the contrastVerification step, you can see it in action.

That’s all there is to it.

Incorporating security guardrails across your SDLC processes helps ensure that your application is meeting your organization’s security strategy by giving your teams the flexibility and telemetry they need to deliver software faster and in a more secure fashion.

Now, you can start to evaluate your application’s security posture (vulnerabilities and exploits) and proceed to enhance your application’s service logic, making the application safer and more secure in the process. Remember, security, especially at the application layer, is required to ensure that your applications are not only safe from attackers, but protected against any type of threat which may compromise your users or IP.