This article summarizes findings originally reported by Data Center Knowledge, drawing on Tripwire’s State of Container Security survey.
The Security Reckoning Containers Bring
Cloud computing forced IT departments to abandon perimeter-based security models. Firewalls protecting the edge of a local network were no longer sufficient once workloads moved to AWS, Azure, and Google Cloud Platform. Now containers are triggering a second wave of security rethinking—and organizations are struggling to keep up.
Containers offer genuine advantages: portability, density, and fast deployment cycles. But those same characteristics introduce new attack surfaces and operational risks. The problem is compounded when CI/CD pipelines push containerized software into production before it has been adequately vetted for security issues.
About the Survey
Tripwire’s State of Container Security report captured responses from 311 IT security professionals who work in environments that include containers. Respondents ranged from teams that were experimenting with containers but not yet running them in production, to organizations deploying more than 1,000 containers. The majority of production deployments involved 100 containers or fewer.
Key Findings
Security Incidents Are Already Happening
Despite containers still being a relatively young production technology for many organizations, incidents are not hypothetical:
- 60% of respondents reported experiencing at least one container security incident in the previous year.
- 6% reported between 26 and 100 incidents in the same period.
- Only about 5% (roughly 2 in 40 respondents on average) said they had no concern about container security at all.
Security Ownership Is Misaligned with How Containers Are Deployed
One of the more revealing findings concerns who owns container security responsibility:
- 46% place container security solely with dedicated IT security teams.
- 12% assign responsibility to a DevSecOps function.
- Only 22% give security ownership to DevOps teams—the teams closest to the containers themselves.
This is a structural mismatch. When rapid CI/CD pipelines push containers into production with little direct involvement from security staff, placing all security responsibility in a siloed security team creates coverage gaps. Tim Erlin, VP of Product Management and Strategy at Tripwire, made the point directly in the report:
“Security can and should be embedded into the DevOps life cycle, incorporating vulnerability and configuration assessment of container infrastructure to monitor risks from build to production.”
Tim Erlin, Tripwire
Security Gaps Are Limiting Container Adoption
Organizations are not ignoring the risks—some are slowing down as a result:
- 42% said they are actively limiting container use because of perceived security risks.
- 82% said they had considered restructuring how security responsibilities are shared across teams.
- Of those, 21% had already reassigned security responsibilities in response to container adoption, and 17% said container adoption was one of several changes prompting a broader rethink of their security model.
Threat Detection Times Are Inconsistent
When asked how quickly they could detect a container compromise:
- Nearly 25% said detection would take days.
- Nearly 50% believed they could detect a compromise within hours.
- 12% estimated detection within minutes.
A detection window measured in days is a serious exposure in a containerized environment where workloads are ephemeral and can be replaced or scaled rapidly, potentially spreading a compromise before it is caught.
Most Expect the Problem to Get Worse
Only 29% of respondents predicted no change or a decrease in container-related security incidents in the coming year. The majority expected incidents to increase. The reasons cited include:
- Containers being used in more mission-critical systems, raising the stakes of any breach.
- A belief that attackers target newer technologies when they are perceived to have weaker defenses.
- A lack of established security best practices specific to container environments.
What Security Capabilities Teams Want
Almost universally, respondents said they wanted additional security tooling for their container environments. The most commonly requested capabilities were:
- Incident detection and response tailored to container workloads.
- Automated isolation of containers exhibiting abnormal behavior.
- Security-focused monitoring, including detection of configuration drift and runtime behavior changes.
- AI-driven security analytics to surface anomalies at scale.
What This Means for DevOps Teams
The survey paints a clear picture: container security is not a future concern—it is a present operational reality. The organizations most at risk are those where security remains entirely separated from the teams building and deploying containers. Several practical steps follow from the findings:
- Shift security left. Integrate image scanning, vulnerability assessment, and configuration checks into the CI pipeline before images reach a registry, let alone production.
- Define clear ownership. Determine whether container security responsibility lives with DevOps, a DevSecOps function, or a shared model—and document it. Ambiguity creates coverage gaps.
- Monitor runtime behavior. Static pre-deployment scanning is necessary but not sufficient. Runtime monitoring to detect drift, privilege escalation, or unexpected network connections is equally important.
- Establish incident response playbooks for containers. Given that ephemeral containers can disappear before forensics are complete, teams need container-aware response procedures.
- Treat containers as part of the threat model. Container escape vulnerabilities, misconfigured orchestration platforms, and exposed APIs are real attack vectors that should be part of any threat modeling exercise.
The organizational restructuring that 82% of survey respondents said they were considering is not optional—it is the prerequisite for deploying containers safely at scale.
Original survey: Tripwire State of Container Security (2018/2019). Coverage by Data Center Knowledge.