Container security incidents are an increasingly common rather than rare exception for development teams.
A new BellSoft survey found that nearly one in four developers has experienced a container-related security incident, highlighting a growing gap between security objectives and the tools and practices organizations depend on.
“The data shows that while security awareness is high, current approaches are unsustainable: 49% lack time for maintenance and 40% update reactively,” said Dmitry Chuyko, Performance Architect at BellSoft in an email to eSecurityPlanet.
He added, “With 48% requesting pre-hardened images as their top solution (more than any other improvement), the data validates hardened images as a practical response to real operational challenges and makes a convincing case for their adoption as the new standard for enterprise platforms.”
Why Container Security Gaps Scale Quickly
Containers sit at the heart of modern application delivery, which means even small security weaknesses can quickly scale across CI/CD pipelines, cloud infrastructure, and production workloads.
BellSoft’s survey shows that while most teams recognize container security as a priority, many continue to rely on reactive approaches that allow known vulnerabilities to remain in production far longer than intended.
Container Incidents Highlight the Remediation Gap
The impact of this gap is already visible. Nearly one in four respondents (23%) reported experiencing a container-related security incident in the past year.
The challenge is not a lack of vulnerability awareness but the pace of remediation.
While vulnerability disclosure-to-fix cycles often stretch from weeks to months, attackers are increasingly able to weaponize newly disclosed flaws within days.
This imbalance leaves organizations operating with known exposures that are difficult to close quickly.
Human Error Remains a Leading Risk Factor
Human error emerged as a significant contributor to container security failures, cited by 62% of respondents.
These mistakes are often the result of complex tooling, limited time and resources, and pressure to deliver software rapidly.
In practice, even well-designed security controls can fail if developers lack the clarity, automation, or bandwidth needed to apply them consistently across environments.
Operational Convenience Expands the Attack Surface
Operational convenience further compounds the problem. Developers reported widespread reliance on shells, package managers, and common utilities within base container images.
While these tools are valuable during development and debugging, they expand the attack surface in production.
Package managers, in particular, increase risk by enabling runtime installation of additional components — many of which are unnecessary, untracked, and introduce new vulnerabilities over time.
Bloated Base Images Increase Vulnerability Exposure
Base image selection adds another layer of risk. More than half of respondents said they use general-purpose Linux distributions such as Ubuntu, Debian, or Red Hat–based systems in their containers.
These images often ship with hundreds of packages that applications never use, yet each one represents a potential vulnerability that must be monitored and patched.
When a new CVE is disclosed, security teams must assess and coordinate remediation across large numbers of container instances, regardless of whether the affected package is relevant, increasing operational overhead and slowing response times.
Reactive Security Controls Dominate Container Environments
Despite these challenges, most organizations surveyed continue to rely on basic, reactive security controls.
Trusted registries and vulnerability scanning tools were the most commonly adopted measures, while more proactive approaches — such as software bills of materials (SBOMs), image signing, or hardware-based isolation — remain less common.
Notably, 10% of respondents said they use no additional container security measures beyond standard Docker or Kubernetes tooling.
Update Delays Leave Known Vulnerabilities in Production
Update practices further illustrate the issue. While some teams update container images with every release or in response to critical vulnerabilities, one-third reported updating monthly, rarely, or only a few times per year.
In today’s threat landscape, these delays leave known vulnerabilities in production long after exploits become available.
Compounding these challenges is the tension between security and performance. Although security ranks as the top stated priority when selecting base images, teams must also consider image size, runtime efficiency, and cost.
Java applications introduce additional complexity, as most respondents said they rely on general-purpose JDKs that were not designed for containerized environments and often ship with known vulnerabilities.
Optimizing these runtimes requires specialized expertise, increasing engineering effort and cloud costs.
As a result, many teams are forced into a trade-off between investing time in tuning and patching or accepting higher risk and inefficiency — an approach that becomes increasingly difficult to sustain as container environments scale.
How organizations can reduce container security risk
Reducing container security risk requires more than reacting to vulnerabilities after they appear in production.
As attack timelines continue to shrink, organizations need a layered approach that minimizes exposure from the outset while improving detection and response capabilities.
- Use pre-hardened, security-focused base images to reduce vulnerability exposure and operational overhead.
- Minimize tools and packages in production images and separate debug builds from runtime images.
- Increase container image update frequency and automate rebuilds when base images or dependencies change.
- Embed security controls earlier in CI/CD pipelines rather than relying solely on post-deployment scanning.
- Enforce image provenance, least-privilege runtime settings, and workload isolation to limit blast radius.
- Improve runtime visibility by monitoring container behavior for anomalies and configuration drift.
- Validate and regularly test incident response plans to ensure teams can quickly contain and recover from container-related security incidents.
These steps help organizations strengthen container security across build, deployment, and runtime environments.
Rethinking Container Security at Scale
The survey findings suggest that container security challenges are driven less by a lack of awareness and more by the difficulty of sustaining effective practices at scale.
As environments become more complex and attack timelines shorten, organizations that rely primarily on reactive controls may find it increasingly difficult to keep up.
Embedding security into container foundations through hardened images, simpler tooling, and automation can help reduce risk while supporting efficient, scalable operations.
These challenges are prompting many organizations to explore zero-trust solutions that limit implicit trust and continuously verify access across containerized environments.
