Cloud Native Best Practices: Security Policies in CI/CD Pipelines
With the continual leftward shifting movement of traditional DevOps responsibilities, organizations can now detect security issues earlier in the software development lifecycle (SDLC). Using CI/CD tools such as Jenkins, GoCD, or Bamboo, organizations can continually develop, test, and ship applications. As containers are becoming the architecture of choice for cloud native applications development, developers are relying on container images from well-known repositories for their development needs.However, even container images from trusted repositories may still contain vulnerabilities that can make applications susceptible to attacks. Furthermore, software dependencies such as packages and libraries that are used during development of the applications may contain vulnerabilities.
To make sure organizations are reducing the potential attack vectors and eliminating risks, the sooner vulnerabilities are identified, the better. Providing security teams with the tools to block non-compliant images within the CI/CD pipeline is your first line of defense. Scanning images for vulnerabilities, secrets, and malware during the development stage allows security teams to enforce the organization’s image assurance policies to block non-compliant images and alert the developers to the reasons.
At this point you may ask yourself Well, I get that it’s important to scan the images my developers use, but how do I get started, and how do I make sure I don't slow development down?
Let’s look at the benefits of scanning images within the CI/CD pipelines, discuss the best practices, and show how Aqua Cloud Native Security Platform (CSP) applies them:
Set up Assurance Policies
By adding Aqua CSP as a security gate to your CI/CD pipelines, you ensure that the applications that you deliver passed the security checks, as specified by Aqua CSP’s Assurance Policies. Assurance Policies are security policies that block non-compliant images from moving through the CI/CD pipelines, based on highly flexible rules that apply not only to vulnerabilities, but also to other security issues such as privileges, user space, embedded secrets, and malware. You can create as many assurance policies as you need and assign dedicated policies to each pipeline. For example, you can define assurance policies that will apply only to the development pipeline, and others for your release pipeline.
Permit Approved Base Images
Aqua CSP identifies the base image of a scanned image and can be set to permit only images from a list of approved base images. For example, if alpine:3.3 is an approved base image, and a developer built an application that uses an alpine:2.2 image or any other base image, Aqua CSP fails the application in the CI/CD pipeline. This practice allows you to minimize the attack surface and only use base images that are approved by your security teams, making images management process controlled and practical.
Flexible Exceptions Management
Not every vulnerability that Aqua CSP identifies has an available fix, and not every vulnerability can be addressed immediately. There are several ways that you can handle vulnerabilities exceptions in Aqua CSP —
Acknowledge a specific vulnerability
Acknowledging a vulnerability means that the product does not fail the image based on the defined vulnerability. You can choose to acknowledge the vulnerability for a specific image, for the entire repository, or for all images. You can also set a time limit after which the rule is deleted. For example, you can choose to ignore CVE-2019-1234 for the 45 days, during which time the image is not blocked. After the elapsed time, Aqua CSP enforces an assurance policy and blocks images with the specific vulnerability.
Policy level exception
You can configure an assurance policy to ignore vulnerabilities that do not have an available fix, ignore vulnerabilities that were published within a specific timeframe, for example, within the last 30 days, or specify vulnerabilities to ignore in specific CI/CD pipeline.
Whitelisting an image means that you approve the image for deployment, regardless of its compliance status. Whitelisting applies to all security issues present in the image, and not to a specific vulnerability.
The assurance policies’ flexible exception management enables you to control how to handle vulnerabilities in the pipelines. You can strike a balance between security needs and development efficiencies. You can secure images as they move through the pipeline, notify developers of vulnerabilities and of how to fix them, while not failing builds and images by selectively handling vulnerabilities.
Where do you go from here?
Now that you know why you would want to integrate Aqua CSP into your CI/CD you are almost covered. Next, you want to make sure nobody can run unauthorized container images manually if they gain access to your container runtime. To that end, you deploy the Aqua Enforcer on your container host to enforce runtime policies to block unauthorized images from running in your production environment. This stage takes you to the realm of runtime container protection to secure containers at the operating-system call level and leverages more of Aqua CSP’s unique runtime protection.