In the midst of developing the survey instrument for the 2018 edition of the Cyberthreat Defense Report (prospectus here), I find myself thinking about one of the “areas to watch” we highlighted in the 2017 edition, published this past March: container security.

 Because they offer developers numerous compelling benefits – including simple packaging, rapid deployment, reduced environmental dependencies, and horizontal scalability – container technologies/solutions such as Docker are here to stay. This situation, however, presents a major challenge from a security perspective. Not only are containers a new/unfamiliar technology (at least to security professionals), but also, practically by definition, they reduce transparency and auditability. And don’t even get me started on governance and the sticky issue of who owns which pieces of the security pie as we continue the DevOps-induced “shift left” that containers is enabling (along with a host of other technologies). That’s a topic for another post/day.

What I can say now, though, is that security teams looking to get in front of this latest wrinkle in the application security landscape need to recognize that container security is still immature. As a result, typically it will be necessary to look beyond the organization’s container technology provider(s) to establish comprehensive defenses. As to what these defenses should include, we recommend enterprises take a multi-layer approach to container security by identifying and applying a combination of best practices (e.g., least privileges), existing countermeasures, and emerging technologies across each of the following areas:

• The build environment (e.g., controlling access/usage of build tools and security testing for the code included in a container)
• The container environment (e.g., controlling containers’ permissions and vetting their contents)
• Runtime protection (e.g., protecting the container engine and host OS from any malicious containers and providing network-layer isolation)
• Monitoring and auditing (e.g., to verify that both your containers and security controls are operating as intended)

I realize that’s a pretty high-level recipe for container security. But my expectation is that a mountain of additional details is right around the corner. Indeed, from where I’m sitting, 2018 is shaping up to be the year of everything DevSecOps, where a large percentage of enterprises will be spending significant time (and money) on what needs to be done from a security perspective to account for the ongoing transformation of application development, architectures, and delivery models. For all you security vendors out there, if you haven’t already figured out how your solutions apply in an IT “world” featuring CI/CD, microservices, APIs, containers, etc., then you’d better get moving. (Hint: give us a call, because we can help!)