Seguridad de contenedores Java pre-hardened: 48% de devs quiere delegarla, según BellSoft
La seguridad de contenedores Java pre-hardened se está consolidando como prioridad operativa en equipos de desarrollo: un 48% de desarrolladores encuestados por BellSoft afirma que prefiere usar imágenes endurecidas de un proveedor en lugar de tomar decisiones y asumir la gestión de vulnerabilidades por su cuenta. El dato llega en un momento en el que la seguridad de la cadena de suministro (supply chain) y la exposición de runtimes en Kubernetes presionan a los equipos con ciclos de parcheo cada vez más exigentes.
BellSoft, proveedor del Liberica JDK, indica que consultó a 427 desarrolladores durante Devoxx para su informe 2025 State of Container Security, con el objetivo de entender criterios de selección de imágenes base, prácticas de seguridad y fricción operativa en entornos containerizados.
Seguridad de contenedores Java pre-hardened: la seguridad domina la elección
En la selección de una imagen base, los encuestados situaron la seguridad como el factor más relevante (29%), por delante de rendimiento (21%), tamaño de imagen (17%), soporte Java (17%), facilidad de uso (11%) y cumplimiento de licencias (4%). La lectura es clara: el “riesgo CVE” y el control del contenido del contenedor pesan más que la comodidad del stack o el footprint, aunque ambos sigan siendo variables críticas en producción.
Esa preferencia se entiende mejor con otro dato: el 23% asegura haber sufrido incidentes de seguridad relacionados con contenedores en el último año, un indicador de que los problemas no son hipotéticos y que, para una parte del ecosistema, ya han tenido impacto directo en operaciones o producto.
Herramientas comunes, resultados contradictorios
BellSoft sostiene que parte del problema es una contradicción entre la prioridad declarada (seguridad) y la base tecnológica elegida. Según el estudio, el 55% utiliza distribuciones Linux de propósito general y el 69% usa JDKs de propósito general. La empresa argumenta que este enfoque añade “bloat” (paquetes innecesarios), amplía la superficie de ataque y obliga a invertir más tiempo en hardening, escaneo y optimización frente a alternativas pre-hardened.
Por qué la seguridad de contenedores Java pre-hardened se vuelve un atajo operativo
Al preguntar por el origen de los errores de seguridad en contenedores, los desarrolladores señalaron principalmente el factor humano: 62% atribuyó los fallos a errores humanos. Le siguen dificultades de parcheo (36%), ventanas de exposición antes de que exista parche disponible (32%) y falsos positivos en herramientas de scanning (29%). A esto se suman restricciones organizativas: falta de tiempo y recursos (49%) y baja priorización interna (36%).
En este contexto, el atractivo de la seguridad de contenedores Java pre-hardened es desplazar parte del trabajo recurrente (mantenimiento, remediación y endurecimiento) hacia el proveedor de la imagen, reduciendo carga operativa y costes asociados, según declaró el CEO de BellSoft, Alex Belokrylov.
Qué controles de seguridad dicen usar las organizaciones
Los encuestados reportaron prácticas diversas para gestionar el riesgo en contenedores: uso de registros de contenedores “de confianza” (45%), vulnerability scanning (43%), generación de SBOM (18%), image signing (16%) y aislamiento por hardware (6%). Un 10% indicó no aplicar medidas adicionales más allá de herramientas estándar, una señal de madurez desigual en seguridad de supply chain.
Contexto: supply chain, SBOM e imagen base
Aunque la encuesta se centra en desarrolladores Java, el patrón es transversal en DevSecOps: la imagen base y su mantenimiento condicionan la postura de seguridad, desde la exposición a CVEs hasta la capacidad de demostrar procedencia (provenance) y control de dependencias. Iniciativas como SBOM e image signing apuntan a reforzar trazabilidad y verificación, pero su adopción aún es limitada según las cifras compartidas por BellSoft.
Para referencias de alto nivel sobre prácticas de seguridad en contenedores y cadena de suministro, puede consultarse la documentación oficial de Kubernetes sobre seguridad y hardening: https://kubernetes.io/docs/concepts/security/ y las guías de seguridad de contenedores de NIST (National Institute of Standards and Technology): https://www.nist.gov/.
La seguridad de contenedores Java pre-hardened seguirá ganando peso
Con incidentes reportados, ventanas de parcheo difíciles de controlar y el factor humano como principal fuente de errores, la seguridad de contenedores Java pre-hardened aparece como una respuesta pragmática a la presión por reducir superficie de ataque sin multiplicar tareas de mantenimiento en equipos ya limitados. El debate que se abre para 2026 no es si la seguridad importa, sino qué parte de esa responsabilidad se internaliza y qué parte se externaliza hacia proveedores de imágenes y runtimes.
