In my previous blog, I discuss Docker’s introduction of containers. This new technology is revolutionizing applications and application development. However, it also limits the visibility and understanding of what comprises an application. Instead of a single tar, war or rpm, applications are now comprised of many container images. These images are then deployed across various hosts and locations. The first step is to understand what’s in the container image, commonly known as static analysis.
The proliferation of DevOps and containers allows developers to quickly develop applications by pulling pre-built container images from a container registry. The registry controls how container repositories create, store, and access container images. However, using pre-built container images creates a few challenges for both development and security teams. Some of these challenges also apply to creating custom container images. Let’s look at each of these challenges separately.
Understanding the Software Composition of a Container Image
The first challenge is understanding what’s the software composition of a container image. Containers include system binaries, software libraries, and other dependencies. This inventory is critical for both development and security teams, as they build and secure applications.
A static analysis of the container image is the best way to understand the software composition of that image. This analysis needs to be performed once a container has been created and stored in the container registry. This analysis will unpack the container image and lists all of the layers contained within the container image, including:
- system binaries,
- software libraries, and
- other dependencies,
all with detailed version information. By providing complete and continuous visibility into what’s in the container image, a complete software inventory is maintained. This is the first step required to protect the application.
Identifying Vulnerabilities within Container Images
The next challenge is identifying vulnerabilities within each of these layers. Yes, the need to scan for known vulnerabilities is still required for container images. Gartner estimates that through 2020, 99% of vulnerabilities exploited will continue to be ones known by security and IT professionals for at least one year.
Once the software composition of the container is understood, a vulnerability analysis of all of the system binaries, software libraries, and other dependencies is performed. By identifying known vulnerabilities after the build process, security teams see the potential risks in containerized applications before they are deployed. This prevents vulnerable containers from being released into production. In addition, continuous monitoring for new vulnerabilities allows the security team to proactively reduce the application attack surface. As new vulnerabilities are identified, both the development and security teams can mitigate risks in previously approved contained images.
Enforcing Security and Compliance of Container Images
The last challenge is enforcing security and compliance of container images. As DevOps accelerates deployment of containers into production, security teams need to ensure that container images are secure and compliant. Compliance includes business requirements, corporate policies, and regulatory mandates. This analysis ensures that containers are configured correctly at runtime.
To streamline the process, rules and policies are enforced after the static analysis of the container image is completed. Developed by the security team, these rules and policies include vulnerability criticality, software version(s), open source software, and licensing. This analysis prevents non-compliant containers from being deployed by the container orchestrators. By seamlessly integrating with your existing CI/CD process, development and security can fully automate the enforcement of security and compliance policies.