Spring Developers Have a Blindspot When It Comes to Container Security
A survey from BellSoft found that Spring developers don’t know their Dockerfiles affect their security posture, aren’t using hardened images and can’t name their compliance framework, exposing their organizations, applications and users to considerable risk
San Jose, California (May 21, 2026) BellSoft announces the publication of a new report, “Security in the Blind Spot: What Spring Developers Don't Know About Their Own Containers,” including the results of a survey of developers conducted last month at Spring I/O in Barcelona.
BellSoft surveyed 250 Spring developers, DevOps engineers and Java architects on-site at Spring I/O 2026, one of the most significant annual events in the European Java ecosystem. The survey probed not just tool adoption but the underlying knowledge gaps, decision-making structures and practices that determine whether Java container deployments are secure.
Here are the key findings:
64% of Spring developers didn’t know their Dockerfile was a security risk
- The most significant finding in this survey was not a gap in tooling but knowledge. Sixty-four percent of respondents at Spring I/O, among the most engaged practitioners in the European Java ecosystem, had never considered that Dockerfile authoring decisions directly affected their security posture.
42% of survey respondents had never heard of hardened images
- Only 22% of respondents currently use hardened container images in production, and 42% have never encountered the concept at all. This is a structural awareness gap: adoption cannot outpace knowledge. The 14% who said they are interested but haven’t started yet, and the seven percent who are planning adoption, represent a pipeline, but one that requires education before it converts to practice.
44% of engineers couldn’t name the compliance rules governing their container stack
- DORA and ISO 27001 each applied to 22% of surveyed organizations, with NIS2 adding an additional 12%. These are not aspirational frameworks. They are in force today, with binding requirements for software supply chain security, vulnerability management and digital resilience. Their engineering implications are direct: image provenance, CVE patching cadence, SBOM generation and incident response all fall within scope.
- And yet, 44% of respondents answered “not sure, managed by another team,” when asked about their compliance framework. This is not necessarily negligence: large organizations route compliance through dedicated GRC functions, and developers are often shielded from the specifics. But when engineers don’t know which frameworks apply, they cannot build systems that meet them. The connection between daily engineering decisions (base image selection, patching cadence, signing, etc.) and regulatory obligations must be better understood at the practitioner level.
16% of respondents apply zero of the five most important container security practices
- These five practices -- scanning, hardening, patching, SBOMs and image signing -- form a layered container security defense. Each layer compensates for the gaps in the others. Fewer than 2% of respondents have all five in place, approximately 65% apply zero or one practice, and 16% apply none at all, relying on cloud providers to manage a security domain that cloud providers explicitly do not own under the shared responsibility model.
“Container security is no longer a niche concern for platform engineers,” said Alex Belokrylov, CEO at BellSoft. “Developers are woefully under-informed about the scope of this issue, and the data is clear: controls embedded at the platform level achieve universal, consistent coverage, whereas controls that depend on individual developer awareness do not. The urgent priority is education, the second is automation.”
The complete BellSoft 2026 Spring I/O report can be found here.
