Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

The Silence of the Lambs: Inspecting binaries with Jenkins

0
0

Security is an overloaded term with varying meaning in different contexts. For this contribution, I consider security as the sum of rules regarding vulnerabilities (Common Vulnerability and Exposure, CVE), in binaries. In a past blog post, we’ve identified SonarQube already, as a very helpful tool to identify flaws in source code, particularly concerning reliability (bugs), vulnerabilities (security, e.g. CWE, that is common weakness enumaration, and OWASP, that is the Open Web Application Security Project), and maintainability (code smells). Now it is a good time to add another tool to the chain, that is Twistlock, for inspection binaries for security issues. Features of Twistlock include

Compliance and vulnerability management, transitively

Runtime defense

Cloud-native CI/CD support

Broad coverage of supported artifact types and platforms

API, dashboards, and Jenkins integration, with strong configuration options

The underlying use case can be derived from several real-world security initiatives, in enterprises, based on given containerized applications. In practice, it is not a surprise that after adding such new quality gates, you identify historically grown issues. However, there are many good reasons to do so. You don’t need any Word documents to check any governance criteria manually, rather execution and reporting are done automatically and also part of the actions are taken automatically. And above all, of course, your application is quality assured regarding known vulnerability issues, aligned with the DevOps approach: development is interested in quick feedback whether their change would introduce any vulnerabilities, and operations is interested in insights whether and how running applications are affected if a new CVE is discovered.

The term DevSecOps was coined to explicitely add security concerns to DevOps. In my opinion, security is already inherent part of DevOps. Thus, there is no strong reason to introduce a new word. Surely, new words are catchy. But they have limits. Or have you ever experienced NoDev, the variant of DevOps where features are suddenly falling from the sky and deployed to production automatically?

Conceptually, container inspection is now part of the delivery pipeline and Twistlock processing is now triggered once we have produced our Docker images, see below, in order to get fast feedback.


The Silence of the Lambs: Inspecting binaries with Jenkins

Software is staged over different environments by configuration, without rebuilding. All changes go through the entire staging process, although defined exception routines may be in place, for details see Michael Hüttermann, Agile ALM (Manning, 2012). The staged software consists of all artifacts which make up the release, consistently, including the business application, test cases, build scripts, Chef cookbooks, Dockerfiles, Jenkins files to build all that in a self-contained way, for details see Michael Hüttermann, DevOps for Developers (Apress, 2012).

This blog post covers sample tools. Please note, that there are also alternative tools available, and the best target architecture is aligned with concrete requirements and given basic conditions. Besides that, the sample toolchain is derived from couple of real world success stories, designed and implemented in the field. However, this blog post simplifies and abstracts them in order to stay focussed while discussing the primitives of delivery units. For example, aggregating multiple Docker images with ASCII files, does not change the underlying primitives and their handlings. For more information on all parts of the blog post, please consult the respective documentation, good books or attend fine conferences. Or go to the extremes: talk to your colleagues.

In our sample process, we produce a web application that is packaged in a Docker image. The produced Docker images are distributed only if the dedicated quality gate passes. A quality gate is a stage in the overall pipeline and a sum of defined commitments, often called requirements, the unit of work must pass. In our case, the quality gate comprises inspection of produced binaries and it fails if vulnerabilities of severity 'critical' are found. We can configure Twistlock according to our requirements. Have a look how we’ve integrated it into our Jenkins pipeline, with focus on detecting vulnerabilities.

Jenkinsfile (excerpt): Twistlock inspection triggered

stage('Twistlock: Analysis') { (1) String version = new File("${workspace}/version.properties").text.trim() (2) println "Scanning for version: ${version}" twistlockScan ca: '', cert: '', compliancePolicy: 'critical', \ dockerAddress: 'unix:///var/run/docker.sock', \ ignoreImageBuildTime: false, key: '', logLevel: 'true', \ policy: 'critical', repository: 'huttermann-docker-local.jfrog.io/michaelhuettermann/alpine-tomcat7', \ (3) requirePackageUpdate: false, tag: "$version", timeout: 10 } stage('Twistlock: Publish') { (4) String version = new File("${workspace}/version.properties").text.trim() println "Publishing scan results for version: ${version}" twistlockPublish ca: '', cert: '', \ dockerAddress: 'unix:///var/run/docker.sock', key: '', \ logLevel: 'true', repository: 'huttermann-docker-local.jfrog.io/michaelhuettermann/alpine-tomcat7', tag: "$version", \ timeout: 10 }

1 Twistlock inspection as part of the sequence of stages in Jenkinsfile 2 Nailing down the version of the to be inspected image, dynamically 3 Configuring analysis including vulnerability severity level 4 Publishing the inspection results to Twistlock console, that is the dashboard

Now let’s start with the first phase to bring our application in shape again, that is gaining insight about the security related flaws.


Viewing all articles
Browse latest Browse all 12749