Developers and DevOps teams have been key drivers of container adoption. The practice of DevSecOps embeds security right into today’s modern workflows without adding unnecessary friction from the security side of the organization. That doesn’t mean security teams are left out. On the contrary: by integrating with the tools developers are already using, like CircleCI, standards set by security teams are continually applied as part of the build and deploy process.
Implementing DevSecOps by scanning container images before they run in production yields benefits like providing quick feedback to developers and keeping insecure or non-compliant workloads out of production. The quality gates around security and compliance come from consultation with the security team and are automated as part of the CI process. Thus, developers get quick feedback and can fix security vulnerabilities and compliance issues while they’re still in development of a feature, rather than incurring the costs of context-switching, or worse, the risks of releasing vulnerable code to production. In this way, setting security and compliance quality gates during the CI/CD process can drastically enhance the security of developers’ containers without slowing them down.
Using Twistlock via the CircleCI Orb Registry
The Twistlock orb can be found in the CircleCI Orb Registry. Additionally, our GitHub repo includes the key details about configuring your Twistlock license, setting up credentials for a CI User role within Twistlock, and other parameters, commands, and scripts that may be helpful.
Scanning images with twistcli
The CircleCI orb leverages
twistcli, our command-line control and configuration tool. The
twistcli tool supports scanning images for vulnerabilities and compliance issues and integrates with any CI workflow without needing a native plugin.
Below, you can see a sample
.circleci/config.yml file that will scan your images following builds in CircleCI before the image is pushed to your container registry:
version: 2.1 orbs: twistcli: email@example.com jobs: docker-build-and-save: executor: twistcli/default steps: - checkout - run: 'docker build -t myrepo/myimage:tag .' - run: mkdir -p workspace - run: 'docker save myrepo/myimage:tag -o workspace/image.tar' - persist_to_workspace: root: workspace paths: - image.tar workflows: scan-image: jobs: - docker-build-and-save - twistcli/scan-image: requires: - docker-build-and-save context: tl_scan_context image: 'myrepo/myimage:tag' imagetar: image.tar vuln-thresh: critical comp-thresh: '' only-fixed: true
In the sample
comp-thresh refer to the specific severity levels Twistlock will alert on or block in each build. While many users may choose to simply scan their images for vulnerability or compliance issues, you can customize these settings to block a build from pushing an image to your registry (as shown in the following screenshots) if it doesn’t meet your security requirements. For example, many users choose to block a critical vulnerability from progressing to their container registry if a known vendor fix is available.
Additionally, you have the option to set
only-fixed to either true or false to only identify issues that have a known vendor fix available.
For an in-depth walkthrough of the entire sample
config.yml file, you can hop over to this specific section of the Twistlock orb GitHub repo.
Seeing scan results within CircleCI
Once your CI user role and scripts are configured, you can see the vulnerability scan results of each build within CircleCI and the Twistlock Console. Below, you can see an example CircleCI workflow where I scan a Docker build:
Additionally, I can view detailed scan results that surface CVEs, package information, vendor fix status, and severity. I am also able to see compliance checks that look at over 300 Docker, Kubernetes, and Linux CIS Benchmarks:
If you are interested in a more global view of all your scan results across teams and environments, you can view all the scans within the Twistlock Console by navigating to Monitor > Vulnerabilities > Twistcli Scans. There, you can see the status of each build or click on any scan to see more detailed scan results just like you would in CircleCI. In the screenshot below, the Status column indicates that all of my scans met my policy requirements except one near the bottom that failed my policy:
We’re proud to be working with CircleCI to embed security into DevOps workflows. To learn more about ways you and your teams can operationalize DevSecOps, check out our infographic 7 Tips to Navigate Operationalizing DevSecOps.
Jeremy Adams brings over 10 years of IT ops and automation experience to Twistlock. There, he works with partners throughout the cloud native ecosystem to integrate security into their DevOps workflows to release secure applications and protect them from active threats. Previously, Jeremy worked at Puppet and Sun Microsystems in customer-focused technical roles. He is an Army veteran and happy transplant to Portland, Oregon.