Survey: Spring Developers Have a Blindspot When It Comes to Container Security

SAN JOSE — A survey from BellSoft found that Spring developers don’t know their Dockerfiles affect their security posture, don’t use robust images and can’t state their compliance framework, exposing their organizations, applications and users to greater risk.

BellSoft surveyed 250 Spring developers, DevOps engineers and Java designers on site at Spring I/O 2026, one of the most important annual events in the European Java ecosystem. The study investigates not only the adoption of tools but the existing knowledge gaps, decision-making frameworks and processes that determine whether the deployment of Java containers is secure.

Here are the main results:

64% of Spring developers didn’t know their Dockerfile was a security risk

• The most important finding of this study was not a gap in tool use but knowledge. Sixty-four percent of respondents at Spring I/O, among the most engaged employees in the European Java ecosystem, did not think that decisions approving Dockerfile directly affected their security posture.

42% of the respondents to the survey had never heard of strong images

• Only 22% of respondents use images of solid containers in production, and 42% have never encountered this concept at all. This is a structural awareness gap: acquisition cannot exceed knowledge. 14% who say they are interested but haven’t started yet, while seven percent who plan to acquire represent a pipeline, but one that needs education before it can turn into action.

44% of developers could not name the compliance rules governing their stack of boxes

• DORA and ISO 27001 were each implemented in 22% of organizations surveyed, with NIS2 adding 12%. These are not wish lists. They operate today, with binding requirements for software supply chain security, risk management and digital resilience. Their engineering implications are straightforward: image evolution, CVE patching cadence, SBOM generation and incident response all fall within the scope.
• However, 44% of respondents answered “not sure, managed by another team,” when asked about their compliance framework. This is not necessarily reckless: large organizations comply with the route by using dedicated GRC functions, and developers are often protected from that specification. But if developers don’t know which frameworks work, they can’t build systems that meet them. The connection between day-to-day engineering decisions (base image selection, patch cadence, sign-off, etc.) and regulatory responsibilities should be better understood at the operational level.

16% of respondents use zero of the five most important container security practices

• These five processes – scanning, strengthening, patching, SBOMs and image signing – form a layered container security defense. Each layer compensates for the gaps in the others. Less than 2% of respondents have all five in place, about 65% use zero or one practice, and 16% do not practice at all, relying on cloud providers to manage the security infrastructure that cloud providers do not have clearly under a shared responsibility model.

“Box security is no longer a concern for platform developers,” said Alex Belokrylov, CEO at BellSoft. “Engineers are woefully under-informed about the scope of this issue, and the data is clear: controls embedded at the field level achieve universal, consistent coverage, while controls that rely on the awareness of individual engineers do not. The first priority is education, the second is automation.”