Securing Jenkins – Fast

8631

This post was originally published here by casey pechan.

Jenkins is one of the most popular open source Continuous Integration (CI) tools available. It’s extremely flexible, easy to use, and it performs a critical function in many agile development situations. Using Jenkins for CI allows developers and DevOps personnel to automate the repetitive work of testing application code before releasing. Typically, this testing applies to unit and integration tests, and sometimes static code analysis. In some even more rare cases, Jenkins users perform deeper security testing as a part of the CI process.

Security tools have gained a reputation for slowing down software delivery because of their reputation as being manually driven or difficult to automate. Anything that unnecessarily slows down the agile process is at risk of being sidelined or cut out altogether, and this is the crux of the issue that keeps security and operations teams in opposition of each other.

The operations team doesn’t want to wait on manual security assessments, and these teams tend to avoid including security tools in a process where they slow down a critical step in application iterations. Operations wants to automate for speed, and security wants to make build-time security assessments in the name of achieving a proactive approach to application security.

But now thanks to CloudPassage Halo, both of these needs can be met.

CloudPassage Halo now enables rapid security assessment for containerized applications within the CI process. Meaning, security gets high-value information generated in the CI process, and the time required to perform the assessment is now a fraction of the overall build time.

So here’s how it works

First, Jenkins runs unit, integration, and static analysis tests against your source code. You’re probably already doing this.

Next, Jenkins builds a Docker image based on the contents of your project’s Dockerfile. This, also, is something you probably have in place already.

Finally, Jenkins triggers an analysis of the new container image with the CloudPassage-Jenkins plugin. This is the new part for your process, and setup instructions can be found here. In seconds the image is analyzed for vulnerabilities, the report is produced and stored with the job results in Jenkins, and is accessible through the CloudPassage API and web portal. The build can be configured with a threshold for the number of Halo discovered vulnerabilities, and if the resulting vulnerability count exceeds the threshold, the build will be marked as ‘failed’.

See the below image for an example:

Here you can see the results in the Halo portal:

Final results

As you can see (from the above), Docker image security has now become an aspect of code quality. Thresholds can be set to make security an enforceable aspect of code quality. If too many vulnerabilities are discovered, you must break the build and patch before Jenkins will allow your code to move along the pipeline. Developers can get rapid feedback for security issues, product owners enjoy reduced cost for security defects (because they’re being fixed pre-deploy), and security teams get visibility into application stack vulnerabilities before the code hits production.

Ad

No posts to display