The state of container security: Teams and tools are key to releasing software confidently

Container adoption is ramping up. With software supply chain attacks also on the rise, you need to expand your software security approach. Here's how.

For the most part, the risks that containers pose — and the methods for addressing them — are not fundamentally different from risks associated with other application environments. Even so container security remains somewhat of a black box for the many organizations that are trying to harness the technology to speed up application deployment and efficiencies.

Containers are highly portable because they include everything that an application needs to run, such as dependences and configuration files. So, for development teams, containers offer a way to build an application once and deploy it across on-premises, multi-cloud, and virtualized environments. Container orchestration software such as Docker Swarm and Kubernetes have made it relatively easy for development team to centrally deploy and manage containerized apps.

In development environments, containers have made it easier for developers to automate the pipeline and more efficiently move applications from testing to production. Many organizations are taking advantage of container technologies to migrate internally developed applications to the cloud or to build cloud-native applications from scratch. Server consolidation and multi-cloud adoption have also contributed to container adoption.

The growing adoption of containers has also heightened the need for more security controls around their use. Increasingly, threat actors have begun targeting container environments with DDoS attacks, exploits targeting kernel and container orchestration technologies and other attacks, putting enterprise cloud applications and assets at risk.

Here's what your team needs to know about the state of container security so that you can release your software with full confidence that it is secure.

Container security risks

There's considerable concern particularly about attackers targeting private and public container registries to distribute malware and poisoned software updates to organizations using these repositories. Last year for example, a security vendor discovered five poisoned container images on Docker Hub that were designed to deploy cryptocurrency miners on the networks of organizations that downloaded these application containers.

Some of the malicious containers had misleading titles that suggested they were legitimate and were therefore downloaded thousands of times before being removed from the registry. More recently, an elevation-of-privilege vulnerability in the CRI-O runtime for Kubernetes raised similar supply chain attack concerns because the flaw gave adversaries a way to escape from a Kubernetes container and execute a variety of malicious actions on the host — including poisoning other containers.

Containers are nothing more than a stack of operating system and application packages bundled together that are vulnerable to security issues like any software environment, said Chris Romeo, CEO of Security Journey.

"The attacker's focus on the software supply chain is the cause of the bulk of threats against container security in recent years." 
—Chris Romeo 

Attackers can exploit these vulnerabilities to compromise a build pipeline, for example by poisoning an app container that is used by others, or by planting a poisoned container in a repository.

"Attackers focus on the build pipeline as a source of weakness. [They] are going after the pipeline, and the pipeline is where container images are built."
—Chris Romeo

With the build pipeline a target of attackers, software teams need visibility into compromises or tampering with heir pipelines, which can then poison the container images being produced. 

Palo Alto Networks and others have identified multiple security issues tied to container environments. These include issues tied to vulnerabilities, malware, software signing, and secrets in container images, hosts, runtimes, registries, and orchestration technologies, all of which organizations need to be aware of — and actively securing them. These issues are a reality with container images just as they are with other software development practices. 

Best practices like code integrity and maintaining a software bill of materials (SBOM) are critical in container environments. However, such practices can be highly challenging to implement given the sheer number of containers in typical application environments, as well as with how frequently containers are updated, Palo Alto Networks says.

Similarly, registries while critical to bringing a semblance of order for distributing containerized applications, make an attractive target for adversaries seeking to compromise entire environments that depend on them. To mitigate the threat, organizations need to consider implementing controls for continuously monitoring container registries, and for locking down the server and other infrastructure hosting the registry.

Organizations need to be similarly cognizant about and prepared for each of the other container security threats such as those tied to CRI-O runtime, container orchestration and host operating systems and misconfigured container images. In addition, because containers are constantly spun up and down it's difficult for organizations to apply the same security controls to containers as the do to other software.

Challenges to container security

Organizations face multiple challenges when it comes to implementing a container security program that addresses these threats. Chief among them is implementing a trusted image repository and enforcing its usage, said Romeo.

"Too many developers pull Docker images from any source as a starting point."
—Chris Romeo

Choose the right security tools

Choosing the right tool to run within the container to monitor for compromise and evaluate the current security posture is critical. So too is education and awareness for developers about the inherent risks in using containers, orchestration, and images for application development and deployment, Romeo said.

He recommends that development and security teams take the time to learn about tools that are currently available to help organizations secure container environments. They need to understand the capabilities of these tools and recognize the differences in the risks that container environments pose compared to typical app development and deployment pipelines.

"Answer the question are we scanning our containers for vulnerabilities? Are we monitoring running containers for compromise? Scope the depth of the problem, understand it, and then implement solutions."
—Chris Romeo

Lisa Azevedo, CEO of container security vendor Containn, said one big limitation with many current container security products and services is that they are reactive, and designed to detect after-the-fact security vulnerabilities. Many container security products allow organizations to scan for and detect known security issues, but do little to prevent them from happening in the first place. Most tools, at best, allow organizations to get a point-in-time assessment of security vulnerabilities in the container environment, she says.

Currently available container security tools generally are good at detecting existing vulnerabilities, providing a remediation report, and pushing the work of fixing the issues back to the development team. A growing number of tools have also started becoming available that harness machine learning, to predict vulnerabilities in software under development. But they don’t allow security teams an opportunity to stay ahead of the curve, because by the time organizations have a chance to remediate the detected issues, new issues likely have already surfaced, Azevedo said.

Push security further left

The key is to ensure container security by pushing it further left during the build process, Azevedo said. Organizations should be thinking about how to implement container security at scale from the beginning and finding ways to maintain control of container deployments and state. The focus should be on shrinking the attack surface while maintaining control of deployments and container state.

Such capabilities are critical because many organizations are on the cusp of moving away from manual tools to intelligent tools for container development and deployment, Azevedo notes. The goal is to be able to spin up containers that are standardized for specific environments and integrate security and compliance features like those required under different industry regulations and national data security and privacy mandates.

Romeo said tools are now available to help organizations tackle container security issues, but that there are challenges to adoption to be aware of.

"There are solid options both from commercial providers and open-source. Functionally, they provide the capabilities that the enterprise requires. The catch is getting implemented into the program, with developers taking action upon the results of the container security tools."
—Chris Romeo

Rethink your container security regimen

Build pipeline attacks are on the rise, and software supply chain security is front and center. With the potential for attackers to inject malware, tamper or compromise signing, the focus for security teams needs to shift beyond vulnerabilities alone. To ensure container security, you need to know if someone has changed or introduced malware in your container images — just like your code.

Keep learning

• Download the free report: Flying Blind: Firms Struggle to Detect Software Supply Chain Attacks
• See interactive sample reports to help your team stop software supply chain attacks