Container Security Is a Growing Concern for IT Professionals: Key Survey Findings

This article is based on reporting originally published by FierceTelecom, citing a November 2018 survey conducted by Tripwire and Dimensional Research.

Survey Snapshot: Security Incidents Are Common, Yet Deployments Keep Growing

Tripwire, in partnership with Dimensional Research, surveyed 311 IT security professionals who manage container environments at organizations with more than 100 employees. The November 2018 survey produced a sobering set of findings:

• 60% of respondents had experienced a security incident related to container usage in the past year.
• 47% admitted they had deployed containers with known vulnerabilities.
• 94% said they had concerns about container security.
• 71% expected their container-related security incidents to increase in the coming year.

The figure that stands out most is not the 60% who had experienced incidents — that tracks with the general difficulty of securing any new infrastructure paradigm at scale. What is more striking is that nearly half of respondents knowingly shipped containers carrying unresolved vulnerabilities, suggesting that delivery pressure frequently overrides security discipline.

Adoption Is Not Slowing Down

Security concerns have not translated into adoption hesitancy. A separate Red Hat survey conducted around the same period found that container usage was expected to grow by 89% over the following two years. Red Hat’s Margaret Dawson noted in a blog post that confusion persists at the leadership level: roughly half of respondents in that survey were unsure whether containers are inherently secure, and only 42% said containers are easy to set up.

Dawson attributed part of this confusion to mixed messaging from vendors: “Some would have you believe that all containers are created equal and that all containers are inherently secure.” They are not. Containers reduce the operating system footprint to the bare minimum required to run an application, which can improve efficiency over full virtual machines, but that minimalism does not automatically translate to security.

Why Container Security Is Structurally Harder Than It Looks

Robert Haynes, principal technical evangelist at F5 Networks, explained to FierceTelecom that containers introduce security challenges at multiple layers:

• A different application architecture: Containers often accompany a shift to microservices, which changes how applications are built and deployed — not just where they run.
• Kubernetes control plane exposure: Container orchestration platforms like Kubernetes introduce their own attack surface. Compromised containers that can reach the Kubernetes API could, without proper admission controllers in place, execute arbitrary commands on the control plane — including spinning up new containers from an attacker-controlled image.
• East-west traffic risks: Microservice architectures generate substantial service-to-service traffic inside the cluster. Vulnerabilities that were not exposed in monolithic applications can surface when services communicate freely across a shared network.
• Dependency chain risks: Applications running in containers frequently rely on open-source libraries. Haynes cited the November 2018 compromise of the event-stream Node.js library, which was downloaded approximately two million times per week before the issue was identified — a supply chain attack that container-heavy Node.js applications would have been exposed to.

Practitioner Recommendations

Lori MacVittie, also a principal technical evangelist at F5 Networks, offered a practical framework for hardening containerized environments:

“Testing, testing, and more testing. Apps and images should be scanned for vulnerabilities as a part of the build process. Careful attention to networking and architecture, too, can help reduce the potential of exploitation through isolation and segmentation. Protections at the North/South, East/West boundary can help by enforcing real-time inspection of inbound traffic as can requiring authentication and authorization at an application and/or API level. Basically, restrict and inspect traffic inbound to the containerized environment and keep individual containers out of reach. And secure those administrative consoles, please!”

— Lori MacVittie, F5 Networks

Translated into concrete practices, this guidance maps to several well-established DevSecOps controls:

• Shift-left vulnerability scanning: Integrate image scanning tools into your CI/CD pipeline so that known CVEs are caught before an image reaches a registry, not after it is running in production.
• Immutable, minimal base images: Use distroless or minimal base images to reduce the number of packages — and therefore the number of potential vulnerabilities — in each image.
• Network segmentation and policies: Apply Kubernetes NetworkPolicies (or equivalent mesh-level policies) to restrict east-west communication to only the service pairs that require it.
• Admission control: Use Kubernetes admission controllers (e.g., OPA/Gatekeeper, Kyverno) to enforce policy at deploy time — preventing images from unverified registries, containers running as root, or pods without resource limits.
• mTLS for service-to-service traffic: A service mesh can enforce mutual TLS between services, ensuring that east-west traffic is authenticated and encrypted.
• Secure the orchestration control plane: Restrict access to the Kubernetes API server, audit RBAC bindings, and rotate credentials regularly. Exposed dashboards and API servers are a common initial access vector.
• Software supply chain hygiene: Pin dependency versions, verify checksums, and monitor for compromised packages in your dependency tree.

A Measured Perspective: Security Is Solvable

Not everyone in the industry views container security as an existential threat. Arpit Joshipura, general manager of networking and orchestration at the Linux Foundation, argued that the security challenge is not unique to containers:

“Like any other modern software, following secure coding best practices including scanning, vulnerability detection and remediation and isolation is the new way of writing code. Containers are no different and most modern software developers and DevOps processes have security built into the software lifecycles.”

— Arpit Joshipura, The Linux Foundation

That framing is useful. The security discipline required for containers — scan early, segment aggressively, automate validation, enforce policy — is the same discipline required for any software system. The difference is that the speed and scale of container deployments amplifies both the consequences of getting it wrong and the payoff of building security in from the start.

Key Takeaways for DevOps and Platform Teams

• Known vulnerabilities being deployed deliberately is a process and culture problem, not just a tooling problem. Teams need explicit policies — and pipeline gates — that prevent known-critical CVEs from reaching production.
• Kubernetes adds orchestration power but also a significant control plane attack surface. Admission controllers, RBAC, and API server hardening are not optional extras.
• East-west traffic in microservice environments deserves the same scrutiny as north-south traffic. Zero-trust network policies between services are increasingly the standard expectation.
• Continuous delivery pipelines must include automated security validation. In a high-velocity environment, manual security gates become bottlenecks that teams route around.
• Supply chain risk — compromised base images or third-party libraries — is a realistic threat vector. Image provenance verification and dependency auditing should be standard practice.

Container adoption will continue regardless of security concerns. The question for engineering and security teams is whether security controls grow at the same pace as the deployments they are meant to protect.