El ecosistema Java parece una fortaleza, y la seguridad es uno de sus puntos fuertes. Entre las especificaciones de Java, los robustos frameworks como Spring y un sinfín de bibliotecas de terceros, se construye sobre una base de seguridad prácticamente inexpugnable.

Sin embargo, las filtraciones de datos no son una anomalía, sino algo habitual. Desde pequeñas startups hasta conglomerados globales, las filtraciones siguen siendo una amenaza persistente, sistémica y creciente en todo el sector. Si la pila tecnológica es tan buena, ¿por qué los resultados son tan malos?

La respuesta no reside en un único error o vulnerabilidad, sino en una deficiencia metodológica. Construimos sobre una base de seguridad inexpugnable, pero olvidamos que los componentes que utilizamos son como un queso suizo. Cada componente y capa está lleno de agujeros. A menos que se apilen estas capas de forma intencionada para que se cubran mutuamente las deficiencias, una filtración no solo es posible, sino inevitable.

La Montaña: JVM, Frameworks y Bibliotecas

Cuando se habla de seguridad en Java, muchos piensan, por ejemplo:

• Protección del código de bytes para validar estáticamente el binario y los tipos, y evitar desbordamientos de pila, con protección en tiempo de ejecución para cubrir dinámicamente lo que solo se puede detectar durante la ejecución (como la comprobación de límites).
• Gestión de memoria que imposibilita el acceso no válido a la memoria, y cargadores de clases para aislar el código del sistema del código de la aplicación.
• Funcionalidades integradas como JAAS (Servicio de Autenticación y Autorización de Java), JCA (Arquitectura de Criptografía de Java), JSSE (Extensión de Socket Seguro de Java), y más.

Todas estas funcionalidades son excelentes, integradas en el lenguaje y la JVM. Sin duda, también utilizas un framework como Spring y bibliotecas de terceros. Estas aprovechan las funcionalidades integradas de Java y añaden muchas otras.

Dado que ya utilizas tantos componentes de seguridad, ¿cómo es posible que esta enorme cantidad de seguridad no sea segura? ¿Las próximas mejoras de Java, las nuevas funcionalidades de Spring o las bibliotecas de terceros que añadas marcarán la diferencia, o hay algún problema estructural más profundo?

Superando los Agujeros
del Queso

Al observar un bloque de queso suizo, no se puede ver a través de él por completo. Solo se pueden ver los agujeros al mirar una sola rebanada. La pregunta es cómo apilar las rebanadas de este «queso de seguridad» de manera que los agujeros no sean visibles lateralmente.

La seguridad de una aplicación Java abarca tres fases distintas:

• Desarrollo y pruebas: codificación y creación de la aplicación.
• Implementación y mantenimiento: configuración y ejecución de la aplicación.
• Operación y monitorización: garantizar el funcionamiento seguro de la aplicación.

Cada aspecto tiene sus fortalezas, debilidades y, por ende, sus puntos débiles. Si no se presta la debida atención a cada una de estas capas, es probable que se generen vulnerabilidades en todos los ámbitos, lo que podría derivar en una filtración de datos.

La clave está en comprender las diferentes prioridades de cada capa y aprovecharlas.

El desarrollo y las pruebas tienen como objetivo crear una aplicación sólida. Los desarrolladores se centran en lograr la funcionalidad completa minimizando los errores. El enfoque principal es entregar una aplicación funcional y operativa. La seguridad es importante, pero no es la misión principal ni una métrica crítica del equipo.

El despliegue y el mantenimiento buscan fortalecer la aplicación y proporcionar un entorno de producción sólido y estable. El objetivo es crear un sistema fiable y seguro. Si bien se pueden enviar solicitudes de cambio al equipo de desarrollo, el enfoque principal es la administración del sistema.

La operación y la monitorización se centran en la vigilancia. Se busca garantizar que la aplicación funcione correctamente y que no ocurra ningún incidente. Desde el tiempo de actividad hasta el rendimiento y la seguridad, el objetivo es garantizar la continuidad de los servicios.

Cada una de estas capas requiere tanto automatización para reducir fallos como la intervención humana para aplicar el sentido común e identificar cuándo deberían ser diferentes las cosas. Desafortunadamente, usted carece de al menos uno de estos elementos en cada capa.

Sin embargo, incluso con los mejores estándares de codificación y una implementación y mantenimiento cuidadosos, existen vulnerabilidades. Piense en los errores que descubrirá la próxima semana o la siguiente. No se trata necesariamente de ataques de día cero revolucionarios, sino de simples vulnerabilidades de inyección SQL de las que actualmente no es consciente. La única forma de subsanar estas deficiencias es mediante la monitorización regular de la actividad de la aplicación. Dicha monitorización detectará tanto ataques externos como abusos internos.

En resumen, si no aborda los tres aspectos, es probable que sufra una brecha de seguridad sin darse cuenta.

Desarrollo y Pruebas

Las filtraciones de datos se deben, en última instancia, a errores y vulnerabilidades. Esto significa problemas en la arquitectura, el diseño o la implementación. Desarrollar código de alta calidad es fundamental para la seguridad.

Estas son algunas prácticas estándar que siguen las organizaciones:

• Utilice un framework adecuado como Spring y bibliotecas de terceros confiables.
• Emplee metodologías como Agile, Scrum, revisiones de código, entre otras.
• Compilaciones y pruebas de regresión totalmente automatizadas.
• Utilice herramientas para análisis estático (SAST) y análisis dinámico (DAST).
• Siga los estándares de codificación y las mejores prácticas.

Estos son pasos importantes y acertados para mejorar la calidad y la seguridad del código. Sin embargo, no son suficientes, ya que incluso las empresas que siguen todas estas recomendaciones y más sufren brechas de seguridad.

Lo que puede faltar no radica en la automatización ni en las prácticas, sino en el factor humano. Se trata del sentido común o la intuición de un desarrollador sénior o un ingeniero de control de calidad experimentado que pueda identificar posibles fallos de seguridad. Para lograrlo, es necesario invertir en una mejor formación en seguridad y delimitar el campo de especialización requerido.

La Brecha Educativa

No existe ningún secreto que todos deban conocer, ni un solo documento o curso que los ponga al día. Es un proceso continuo que mejora gradualmente las habilidades. Aquí hay algunos ejemplos para explicar mejor el desafío:

Almacenar las contraseñas de los usuarios en texto plano es una práctica universalmente aceptada como inaceptable. Sin embargo, almacenar la contraseña de la cuenta del servicio de base de datos es un desafío, ya que la aplicación necesita acceder a ella. No se puede cifrar mediante hash, y cualquier clave de cifrado será accesible desde el código. Esta es una cuestión compleja que requiere la debida atención, y un desarrollador con conocimientos de seguridad lo comprendería.

Otro tema recurrente: ¿por qué la inyección SQL sigue siendo una preocupación en 2026? Principalmente porque los desarrolladores desconocen cómo ocurre y qué deben evitar. También se debe a que confunden la seguridad del framework con la seguridad absoluta. Usan Hibernate o Spring Data JPA y creen que los protege, pero en el momento en que usan la concatenación de cadenas para construir una cadena JPQL dinámica o una consulta nativa, quedan expuestos. Incrustar literales en SQL siempre es un error. Las variables de enlace deben utilizarse universalmente, ya que separan los literales (datos) del SQL (código) y eliminan el riesgo de inyección SQL.

Muchos desarrolladores enfatizan la sanitización de entradas como una solución universal para abordar innumerables vulnerabilidades de seguridad, incluyendo la inyección SQL. Si bien la validación y sanitización de entradas son prácticas buenas y legítimas, también son síntoma de un problema más profundo. Los desarrolladores hacen suposiciones sobre la entrada y no programan qué sucede cuando no se cumple. Las entradas con etiquetas HTML inesperadas provocan XSS. Las API que contienen nombres de archivo permiten acceder a archivos inesperados, y los parámetros que aparecen varias veces pueden usarse en ataques HPP. Incluso una excepción no controlada al convertir una cadena en un número puede tener consecuencias inesperadas. Esto también forma parte del problema más amplio del manejo de errores que, cuando no se codifica y prueba correctamente, expone al usuario a un ataque.

Un tema relacionado son las prácticas de lanzar excepciones e imprimir sus extensos rastreos de pila. De manera similar, los desarrolladores a menudo muestran mensajes de error detallados de la base de datos. Esto parece una buena idea, ya que ayuda a depurar problemas. Sin embargo, también es así como los hackers descubren cuál es el error y cómo explotarlo. La información detallada de depuración debe estar en los archivos de registro, no en el monitor del usuario.

Como se mencionó anteriormente, estos son solo ejemplos. El problema fundamental en estos y muchos otros casos es la falta de formación y concienciación en seguridad informática en los equipos de desarrollo. Un código de calidad proviene de ingenieros capacitados y con experiencia. Lograr que la aplicación funcione es el punto de partida, mientras que la intuición humana y los conocimientos de seguridad son el nivel máximo. Existe una enorme brecha entre este punto de partida y el nivel máximo, y es ahí donde los hackers acechan.

El Costo Cognitivo

Parte del desafío educativo para los desarrolladores radica en la magnitud del proyecto. La enorme cantidad de frameworks, bibliotecas y herramientas utilizadas para construir la aplicación. Por un lado, esta complejidad aumenta el riesgo de vulnerabilidades en la cadena de suministro. Sin embargo, igual de importante es el costo que implica para la formación y las habilidades.

Cuando los desarrolladores conocen a fondo las bibliotecas y herramientas que utilizan, es mucho menos probable que encuentren errores. Hay una gran diferencia entre usar una API que se aprendió hace cinco minutos y usar una con la que se ha trabajado durante años.

Cuantas más herramientas, bibliotecas y frameworks dependan de un proyecto, menos familiarizados estarán los desarrolladores con cada uno de ellos. La familiaridad superficial inevitablemente provoca errores y fallos de seguridad. Al reducir la complejidad, se permite a los desarrolladores comprender mejor los componentes que utilizan, cómo funcionan y cómo manejarlos.

La Brecha en las Pruebas

La mayoría de las pruebas estándar buscan validar el funcionamiento de la aplicación. Esto aplica tanto a las pruebas de desarrollo como a las de control de calidad. Las pruebas de seguridad, en cambio, deben garantizar que la aplicación sea invulnerable. Esto requiere una mentalidad de hacker que la mayoría de los equipos de control de calidad y desarrollo no poseen.

Las pruebas de seguridad implican probar diversos tipos de entradas no válidas, aplicar condiciones de estrés y de operación extremas, y probar cada parámetro de URL. También implican inspeccionar puntos de acceso internos invisibles para el usuario final, enviar parámetros mediante GET o POST que la aplicación no espera, etc. Así como el control de calidad busca imitar a un usuario común, las pruebas de seguridad deben buscar imitar a un hacker.

Localizar las páginas y llamadas a la API «ocultas» puede ser lo más difícil. La dificultad radica en que nadie las conoce, por lo que nadie las mantiene ni las prueba. Por ejemplo, consideremos una vulnerabilidad de autorización a nivel de objeto (BOLA) en una página o un endpoint de API que no se probó porque solo se usa mediante AJAX o nunca se accede a él.

En definitiva, la cuestión es que los equipos de pruebas necesitan una mejor formación en seguridad, porque si no saben cómo son las vulnerabilidades de seguridad, nunca podrán encontrarlas.

Despliegue y Mantenimiento

El despliegue y el mantenimiento se tratan como algo secundario. No se integran en los requisitos del producto, sino que se gestionan posteriormente a la fabricación del producto. Antiguamente, alguien tenía que averiguar cómo lograr que una aplicación que funcionaba en desarrollo funcionara en producción.

Hoy en día, es el pipeline de CI/CD el que convierte esos pasos improvisados ​​en un proceso automatizado.

El pipeline (o canalización) de CI/CD puede incluir, por ejemplo:

• Compilación automatizada del código desde el control de versiones.
• Prueba de regresión automatizada.
• Análisis automático de la lista de materiales de software (SBOM) para identificar posibles vulnerabilidades en la cadena de suministro.
• Implementación automatizada de imágenes de máquinas virtuales y del software que contienen.

El método anterior dependía de unas pocas personas que sabían cómo implementarlo, lo que conllevaba el riesgo de que cometieran errores o pasaran algo por alto. El nuevo método ha sustituido en gran medida a los humanos por la automatización. Sin embargo, estos procesos garantizan que un error nunca se vuelva a evaluar y quede integrado de forma permanente en el proceso.

El Conflicto de Mentalidad

Otro defecto en el pipeline de CI/CD radica en quién lo construye y mantiene. Por ejemplo, si es un desarrollador, su trabajo consiste en hacer que la aplicación funcione. Cuando los desarrolladores son responsables, pueden flexibilizar una política, abrir un puerto, otorgar un permiso o usar una opción innecesaria para que todo funcione.

El despliegue profesional requiere la mentalidad opuesta: el endurecimiento. Sí, es necesario asegurarse de que todo funcione, pero debe funcionar en el entorno más estricto y restrictivo.

• Minimalismo: Si una biblioteca no es necesaria para producción, no debe instalarse.
• Principio de mínimo privilegio: ¿Realmente necesita la JVM ejecutarse como root? ¿Necesita acceso de escritura a todos estos directorios?
• Configuración estricta: Un archivo de configuración que funciona en desarrollo puede ser un riesgo en producción. Es necesario reforzar la seguridad, deshabilitar la depuración y proteger todo.
• Entorno seguro: Se debe habilitar el firewall, cerrar todos los puertos innecesarios, habilitar SELinux, deshabilitar cuentas, gestionar y proteger los registros, entre otras medidas.

Un ejemplo clásico era el despliegue de aplicaciones Java con un JDK completo. El Kit de Desarrollo de Java (JDK) presenta una enorme superficie de ataque debido a la gran cantidad de compiladores y herramientas innecesarias en producción. Hoy en día, esto se puede solucionar con JLink, GraalVM, etc., pero aún se necesita personal capacitado para ello.

Los procesos de despliegue y mantenimiento son fundamentalmente opuestos a los de desarrollo. Este ámbito corresponde a los administradores de sistemas con conciencia de la seguridad, cuyo objetivo es garantizar operaciones fiables, continuas y seguras. Delegar la gestión del pipeline de CI/CD a personal externo es una receta para los problemas de seguridad.

Mantenimiento

El mantenimiento es donde la vigilancia se desvanece. Cada biblioteca de terceros es una puerta trasera potencial. Lo hemos visto con Log4j y otras. Un escaneo automatizado de la lista de materiales de software (SBOM) es un comienzo, pero no es la solución. El mantenimiento requiere una persona que se preocupe por cada cambio y se asegure de que un parche o una modificación no abra una nueva brecha. Basta con un rol de IAM o una política de red de Kubernetes mal configurados.

Los errores de mantenimiento e implementación no solo están relacionados con Java, pero siempre requieren mayor atención. Así fue como AWS estuvo caído durante 15 horas, cómo River City Media expuso 1370 millones de registros de usuarios, cómo Microsoft expuso 250 millones de registros de soporte al cliente y cómo se robaron los buckets de almacenamiento de Amazon S3 de Capital One.

Al igual que en el desarrollo, la implementación carece de personal experimentado y consciente de la seguridad. La automatización es una herramienta, no una solución. Se necesitan personas que formen parte del proceso de implementación, que conozcan sus complejidades, que estén al tanto de los cambios incorporados al software y que validen constantemente que la producción sea confiable y segura.

Complejidad

Las implementaciones modernas de Java son increíblemente complejas, con una cantidad asombrosa de componentes tanto en la aplicación como en su entorno.

La cantidad de herramientas, frameworks y bibliotecas utilizadas desde el desarrollo hasta la producción es increíble, y un error en cualquiera de ellas puede generar una vulnerabilidad. No solo se trata de errores en esos sistemas, sino también de errores de configuración, incompatibilidades o un simple detalle pasado por alto.

Atrás quedaron los días en que los ingenieros de DevOps conocían los detalles de cada parámetro posible en el puñado de sistemas que utilizaban. Hoy en día, ya es un logro que conozcan todos los sistemas en uso y su funcionamiento general.

Un enfoque es simplificar siempre que sea posible. Considerar la complejidad como un factor de riesgo y buscar reducir el número de herramientas, frameworks e integraciones, además de mejorar el aislamiento. Otro enfoque es invertir en educación, capacitación y mentoría para garantizar que el personal pertinente conozca a fondo cada componente y sus matices. Lo ideal es adoptar ambos enfoques y simplificar a la vez que se mejoran las habilidades.

Operación y Monitoreo

Garantizar el buen funcionamiento y la seguridad del sistema es la capa más crítica, y la seguridad se suele descuidar casi universalmente. Esta capa busca compensar todos los errores, vulnerabilidades, fallos de configuración y otros problemas que se infiltran en la producción. Debería ser la más robusta y recibir la mayor inversión, pero en cambio, se ignora casi por completo.

El Problema del «Arma Automática»

La principal medida de seguridad implementada en producción actualmente es un WAF (Firewall de Aplicaciones Web). Si bien ofrece protección útil, dista mucho de ser suficiente. Su mayor limitación es conceptual. Confiar únicamente en el bloqueo automático es como tener cañones antiaéreos automáticos disparando al cielo.

• Suelen disparar a pájaros o a nada en absoluto (falsos positivos).
• Fallan los bombarderos furtivos (ataques sofisticados).
• El enemigo conoce los planos de estas armas (por ejemplo, las firmas WAF).
• A veces alcanzan un avión enemigo, pero este tiene intentos ilimitados y solo necesita una penetración exitosa.

Es un juego imposible de ganar. Las probabilidades están tan en contra de los defensores que los atacantes siempre ganan. Lamentablemente, esto coincide perfectamente con la realidad.

Para colmo, no te darás cuenta de la derrota hasta meses o años después. Si un atacante elude estas defensas automatizadas, estás a ciegas. En la mayoría de las organizaciones, las brechas pasan desapercibidas durante meses porque nadie lo sabe.

La última línea de defensa debía ser la más formidable y compensar todas las demás. Sin embargo, termina siendo decepcionante y el eslabón más débil de la cadena.

Los Tres Pilares en Tiempo de Ejecución

El principio fundamental de la seguridad es bloquear lo que se pueda y detectar el resto. Solo es necesario detectar a tiempo una vulnerabilidad explotada.

También hay que recordar que existe el peligro interno. Las amenazas internas representan aproximadamente el 20 % de las filtraciones de datos. Por lo tanto, es fundamental identificar los ataques provenientes tanto de fuentes externas como internas: ataques contra vulnerabilidades desconocidas, exploits simples que aprovechan el robo de credenciales o el abuso de privilegios.

Una defensa adecuada se basa en tres principios fundamentales:

I. Controles de detección

Los controles de detección son fundamentales para cualquier sistema de seguridad. Un banco sin cámaras de seguridad ni guardias de vigilancia es simplemente una gran bóveda. Con el tiempo, los intentos y la habilidad necesarios, cualquier bóveda puede ser vulnerada, especialmente una con innumerables vulnerabilidades.

Los controles de detección eficaces requieren:

• Alertas oportunas: Información casi en tiempo real para reaccionar a los ataques con rapidez.
• Informes periódicos: Mayor visibilidad de las actividades sensibles a la seguridad.
• Análisis de anomalías: Identificación de actividades sospechosas individuales entre miles de millones.
• Análisis forense reactivo: Capacidad para investigar eventos pasados ​​y comprender lo sucedido.

Estas medidas estándar permiten cubrir el ciclo completo de seguridad, desde la detección hasta la investigación humana.

II. El factor humano (Análisis forense proactivo)

Las medidas de detección mencionadas son excelentes, ya que están calibradas con mayor sensibilidad que las preventivas, pero dependen en gran medida de la automatización. La automatización es la reacción natural al enorme volumen de actividad y puede filtrar miles de millones de eventos. Sin embargo, no puede aplicar el sentido común.

Se necesita personal de seguridad que interactúe con los datos. El análisis forense proactivo no consiste en esperar a que suene una alarma, sino en analizar el perfil de actividad de la aplicación y preguntarse por qué ocurre. Es una herramienta poderosa para el diseño de controles, la planificación de alertas, informes y anomalías. También es eficaz para identificar deficiencias a medida que el perfil de actividad cambia con el tiempo.

El análisis forense proactivo le ayuda a estar al tanto de lo que sucede sin depender únicamente de los controles automatizados que configuró hace años. Permite que su personal de seguridad supervise la aplicación.

III. Prevención Declarativa en Tiempo de Ejecución

La seguridad integrada de las aplicaciones es rígida. Si se descubre un ataque o una vulnerabilidad hoy, puede llevar semanas corregir el código, probarlo e implementarlo. Se necesita una capa de seguridad declarativa. No una solución RASP compleja con protección automatizada, sino una prevención declarativa sencilla para corregir vulnerabilidades en tiempo real.

Una seguridad eficaz en tiempo de ejecución requiere bloquear la misma actividad que se monitoriza. De esta forma, el equipo puede abordar los ataques detectados. Esto implica bloquear URL e IP visibles en la capa de red, evaluar al usuario en la aplicación o detener actividades más profundas, como las consultas SQL enviadas a la base de datos. Estas políticas deben implementarse instantáneamente en múltiples servidores de aplicaciones, sin cambios en el código ni reinicios del servicio. Cuando se detecta un ataque, la mitigación debería tomar minutos, no días.

No se trata de un arma automática, sino de un rifle de francotirador, apuntando a un objetivo controlado por un ingeniero de seguridad. Ya sea como solución permanente o temporal, la capacidad de actuar permite al personal de seguridad reaccionar sin desconectar toda la aplicación.

Reflexión Final

Proteger una aplicación Java no se trata de encontrar la herramienta perfecta. Se trata de aceptar que todo tiene fallos y de compensarlos. Tu código tiene errores, tu implementación presenta configuraciones incorrectas y tus defensas automatizadas pueden ser vulneradas. Aun así, debes evitar una brecha de seguridad.

La única forma de lograrlo es reforzar la seguridad de forma que los puntos débiles no coincidan. De esta manera, un error no desencadenará una brecha de datos. Debes capacitar a tus desarrolladores en seguridad y en cómo se producen las brechas. Debes capacitar a tus equipos de implementación para que refuercen el entorno. Y, lo más importante, activa la vigilancia en producción y obtén visibilidad y control sobre tu actividad.

Así es como se protege una aplicación, no solo rezando y esperando lo mejor. No sigas haciendo lo que ya está fallando. Puede que no sea una locura, pero sin duda no es una buena estrategia.