What Does It Take to Secure Containers?

Most DevOps professionals who use containers to develop and deploy applications believe software containers provide security, but one company, Aqua Security, argues that containerization is not a protective technology.

In its report "Understanding the cloud native runtime protection security gap," almost all developer and operations specialists — 90% — said they would "feel comfortable classifying containers as a security boundary," and almost three-quarters believe their current suite of software security controls could stop malicious code inserted into the software supply chain. The security firm, however, says such a classification shows that professionals continue to misunderstand the steps needed to make cloud-native applications secure.

In clarifying the company's stance, Amir Jerbi, chief technology officer and founder of Aqua Security, stresses that containers are not a new security technology, and, at the end of the day, nothing is isolated.

"What containers brought to the industry was their ability to take an application and make the application think that it is alone to emphasize isolation," he says. "From a security perspective, this is not a new type of isolation or a new security primitive. It was a very user-intuitive way to run an application using existing primitives to make security management much easier than before."

Cloud-native applications have become an increasingly popular way to deploy software, especially following the increase in remote work caused by work-from-home mandates during the pandemic. Companies use software containerization — the most popular example of which is Docker — to encapsulate software for development and deployment to cloud infrastructure.

Yet most of the security focus of such DevOps pipelines has been on finding vulnerabilities during development, scanning images for vulnerable components, and creating secure configurations. In June, the Cloud-Native Computing Foundation (CNCF) doubled down on this approach, releasing a whitepaper on supply-chain security, aiming to extend trustworthiness all along the software supply chain, from tools to components to distribution.

Creating such a trusted pipeline is difficult, but the consequences of failure are dire, said Justin Cormack, chief technology officer at Docker, in a blog post about the CNCF whitepaper.

"Every time you use software that you didn’t write yourself, often open source software that you use in your applications, you are trusting both that the software you added is what you thought it is, and that it is trustworthy not hostile," he said. "Usually both these things are true, but when they go wrong, like when hundreds of people installed updates from SolarWinds that turned out to contain code to attack their infrastructure, the consequences are serious."

While Aqua Security wants to spur demand for its approach to cloud-native security, the company's argument about the complex process of securing the supply chain is also on point. While containerization facilitates security improvements — such as security-as-code, isolation on the host, and immutable images — containers deployed without thought to security or the supply chain provide no guarantees that malicious code or vulnerabilities may have crept in.

Many DevOps practitioners have not created development-to-deployment pipelines that secure containers along the way. The most deployed security controls for containers include scanning images for vulnerabilities as part of the CI/CD pipeline (59%), vetting software components to limit supply-chain attacks (53%), and deploying firewalls to protect containers (52%), according to the company's survey.

Runtime security can add another layer that foils attacks, but only 24% of respondents to the Aqua Security survey said they plan to deploy runtime technology in the next 12 months to stop attacks in progress.

That's not enough, says Aqua's Jerbi. "It depends on what data you want to protect and what it means to you," he says. "If you have a lot to lose, then you need to add more and more layers to reduce the risk.

Improving container security boils down to a few steps, Jerbi says. The first step, which every company should implement, is to get a good picture of where the security of their cloud infrastructure stands, he says.

"Almost all of our customers start with a focus on visibility," he says. "They want to understand what is the current security posture — what are the risks that they have to worry about today."

Yet many companies get sidetracked after that, focusing on specific problems rather than improving practices. By creating a secure pipeline, rather than focusing on specific classes of vulnerabilities, DevOps professionals can create security best practices that will result in better software overall. More experienced workers surveyed by Aqua Security prioritized the creation of policies for the build pipelines compared with their less experienced colleagues. By shifting security left into the pipeline, better software is produced, Jerbi said.

Finally, runtime security should be implemented to stop attacks in progress, he said.

"They are not waiting until everything is green and healthy and hygiene is perfect, but they add runtime capabilities into their environment," Jerbi says. "This gives them a way to mitigate the risk and prevent unknown attacks."

In the end, having redundant layers of protection is a good thing, and those layers of protection start with the container technology, Docker's Cormack told Dark Reading in an email interview.

"It's a bit nuanced, in general. Even if containers were not a 100% security barrier, they are another layer an attacker has to get through, so they have to chain more attacks, and in general they have been quite good at restricting attacks," he says. "There are some Linux kernel vulnerabilities they do not protect against, but many are restricted or stopped by containers, or are harder to use."