Key Criteria for Evaluating Container Security Solutionsv2.0

1. Summary

Containers have revolutionized the way that IT views servers. While virtual machines (VMs) allowed users to run many logical servers on a single physical machine, containers took the concept one step further, enabling servers to use fewer resources and making them easier both to deploy and dispose of. The result is a proliferation of servers, some with lifecycles—from spin-up to destruction—measured in seconds.

The proliferation of containers has naturally attracted the attention of attackers because the mere existence of containers and container management expands the attack surface by increasing both the software infrastructure footprint and the number of servers running in an organization. Container security was created to address this problem. The tools in this space are specifically aimed at the unique issues that containers generate.

In addition to containers increasing the attack surface, other developments—such as the growth of CI/CD and agile development—are also exacerbating vulnerabilities and having an exponential effect upon corporate security.

What makes things worse is that containers can change so often and so quickly. It’s common now to make a change in an application, run it through the CI/CD process, and change the way the application behaves in a matter of minutes. So, security tools must work to protect containers and do so at the speed of DevOps, or the information security staff will still be reviewing files from multiple DevOps iterations ago.

Protections offered by container security tools can be broken into design-time, build-time, and runtime capabilities, with each step requiring different functionality and integrations.

Design-time considerations include the management of container definition security using an inventory of the elements that make up the software components (a software bill of materials, or SBoM), while build-time concerns include scanning the product as it is produced. There are many possible vulnerability scans, with such scans and scanning for secrets hardcoded into the container. Finally, runtime protection includes watching how the container and its application behave, looking for aberrant behavior that could indicate compromise. It also includes drift detection. While anomalous behavior can occur from undetected rogue sources, it can also occur because the running container has been changed. Notifying IT when change happens is core to runtime protection.

In short, container security aims to address the specific security weaknesses of containers, from design to destruction, anywhere they may reside.

This is the second year that GigaOm has reported on the container security space in the context of our Key Criteria and Radar reports. This report builds on our previous analysis and considers how the market has evolved over the last year.

This GigaOm Key Criteria report details the capabilities (table stakes, key criteria, and emerging technologies) and non-functional requirements (evaluation metrics) for selecting an effective container security solution. The companion GigaOm Radar report identifies vendors and products that excel in those capabilities and metrics. Together, these reports provide an overview of the category and its underlying technology, identify leading container security offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.