10 prácticas recomendadas de seguridad para Maven
Robert Scholte
26 de septiembre de 2018
0 minutos de lectura¡Una vez más, te ofrecemos una guía práctica centrada en la seguridad! Este mes compartimos 10 recomendaciones para mejorar tu dominio de Maven. Maven es, claramente, la herramienta de compilación líder en el ecosistema de Java y JVM. ¡ALERTA DE SPOILER! Los resultados de nuestra encuesta sobre el ecosistema JVM, que se publicarán en octubre, muestran que el dominio de Maven continúa en 2018 y no parece que vaya a cambiar pronto: seis de cada diez desarrolladores usan esta herramienta de compilación en su proyecto principal, como se muestra a continuación.

Esta es nuestra quinta guía práctica del año (¡vaya, cómo pasa el tiempo!). En meses anteriores, ya publicamos guías sobre inferencia de tipos en Java, prácticas recomendadas de seguridad para GitHub, Zip Slip y 10 prácticas recomendadas de seguridad para Spring Boot. Esta publicación se ideó en Creta, mientras descansaba en la playa con el presidente del proyecto Apache Maven, Robert Scholte. Nos sentamos en la gloriosa arena dorada, nadamos en las hermosas y cálidas aguas de Creta y se nos ocurrieron estos 10 consejos de seguridad. No digas que nunca hacemos nada por ti.
1. Cifra tus secretos
Desde Maven 2.1.0, es posible cifrar contraseñas en máquinas de compilación compartidas. Si varios usuarios tienen acceso a una máquina compartida, o si muchos usuarios pueden acceder a un archivo settings.xml, los secretos almacenados deben estar cifrados. Si compartes archivos settings.xml con otros desarrolladores, considera quitar los secretos del archivo para que solo los usuarios autorizados tengan permiso para implementar artefactos de Maven en los repositorios, en lugar de todo el equipo. Estos usuarios autorizados tendrían un archivo settings-security.xml almacenado localmente en su carpeta de configuración de Maven o en algún lugar privado para ese usuario. Si tus compilaciones se ejecutan en una ubicación compartida que usa todo el equipo, debes cifrar los secretos en el archivo settings.xml. Para hacerlo, tendrás que crear una contraseña maestra que puedas almacenar y compartir de forma adecuada.
Puedes crear tanto la contraseña maestra como las contraseñas del servidor con la CLI de Maven, ejecutando el siguiente comando:
Una vez creada, guárdala en el archivo ~/.m2/settings-security.xml de la siguiente manera:
Ahora puedes crear una contraseña de servidor ejecutando el siguiente comando:
Guárdala en el archivo settings.xml de la siguiente manera:
Para obtener más información, consulta la página de documentación de Maven sobre cómo almacenar secretos en el archivo settings.xml.
2. No uses contraseñas en la CLI
En el ejemplo anterior mostramos la forma correcta de agregar secretos a tus archivos de configuración. También hay una forma incorrecta, y queremos asegurarnos de que la conozcas para que puedas evitarla. Una opción heredada de los comandos de la CLI que se muestran arriba permite proporcionar una contraseña en la línea de comandos para ambos comandos de cifrado, como en el siguiente ejemplo:
"10 Aunque esto funcionaría y te permitiría obtener secretos cifrados, nunca debes escribir tus secretos en texto sin formato en la línea de comandos. Estos secretos se guardan en el historial de la consola y se pueden recuperar fácilmente.
3. Usa siempre HTTPS
Los repositorios de Maven pueden ser locales o remotos. Tus repositorios locales, que suelen encontrarse en el directorio ~/.m2/repository/ de tu máquina, son versiones en caché de los proyectos que descargaste anteriormente. Los repositorios remotos pueden incluir Maven Central o un repositorio que haya configurado tu organización mediante Artifactory o una herramienta similar. Puedes ver qué repositorios usas en tu compilación revisando el elemento de tu pom.xml. Como ocurre con la mayoría de las comunicaciones actuales, es muy importante usar HTTPS al conectarse con servicios de terceros, y los repositorios de Maven no son la excepción. Validar que te estás comunicando con los servidores a los que quieres conectarte reduce las probabilidades de sufrir ataques de intermediario o, más específicamente, una vulnerabilidad de descarga de recursos mediante un protocolo no seguro.
Para evitarlo, comunícate siempre con los repositorios mediante HTTPS, incluso si el repositorio está alojado en tu propia organización. Para habilitarlo, asegúrate de que los elementos y de tu pom.xml usen https en sus URL.
4. Revisa el estado de las dependencias
Incorporar dependencias de terceros en nuestras aplicaciones es muy habitual, y los desarrolladores suelen hacerlo sin pensar demasiado más allá de «¿cumple su función?». También es importante que la dependencia esté en buen estado antes de incorporarla a nuestra aplicación. Para evaluar el estado de un proyecto del que estás considerando depender, puedes revisar lo siguiente:
Cantidad de colaboradores activos: los proyectos de código abierto mantenidos por solo una o dos personas pueden ser riesgosos, ya que suelen depender de una sola persona para las actualizaciones y los lanzamientos. Contar con un equipo de colaboradores reduce este riesgo de forma significativa.
Políticas de seguridad documentadas: ofrecer a los usuarios un procedimiento para reportar problemas de seguridad aumenta las probabilidades de que los comuniquen. Asimismo, proporcionar un mecanismo para notificar a los usuarios sobre los problemas de seguridad y sus correcciones a medida que surgen les permite usar las dependencias de forma más segura.
Actualizaciones y lanzamientos regulares: asegúrate de que los proyectos de los que dependes sigan en desarrollo activo. En primer lugar, esto ayudará al desarrollo futuro de tu propio proyecto, ya que sabrás que tus dependencias se mantendrán al día con las características del lenguaje, etc. Desde el punto de vista de la seguridad, es importante saber que los problemas de seguridad que se reporten se atenderán rápidamente.
5. Busca vulnerabilidades conocidas
Los atacantes apuntan cada vez más a las dependencias de código abierto, ya que la reutilización de bibliotecas ofrece muchas víctimas potenciales a quienes intentan aprovechar una vulnerabilidad conocida. Es importante asegurarte de que no haya vulnerabilidades conocidas en todo el árbol de dependencias de tu aplicación.
Usar herramientas como Snyk para analizar los artefactos de compilación de Maven marcará las dependencias con vulnerabilidades conocidas. En un panel, te ofrece una lista de las vulnerabilidades presentes en los paquetes que incorporas mediante tu archivo pom.xml.
Además, te sugerirá cómo corregirlas, ya sea actualizando versiones o aplicando parches creados por el equipo de seguridad de Snyk. Si conectas tu herramienta de administración del código fuente, como GitHub, Bitbucket o GitLab, por ejemplo, podrás corregir automáticamente tus problemas de seguridad mediante una solicitud de cambios (pull/merge request). Snyk sigue protegiendo tu entorno: usa webhooks para analizar automáticamente las futuras solicitudes de cambios y asegurarse de que otros desarrolladores no introduzcan nuevas vulnerabilidades en el proyecto.
Snyk está disponible como interfaz web y también como CLI, así que puedes integrarlo fácilmente en tu entorno de CI y configurarlo para que detenga la compilación de Maven cuando haya vulnerabilidades cuya gravedad supere el umbral que configuraste.
Puedes usar Snyk gratis en proyectos de código abierto o en proyectos privados con una cantidad limitada de análisis mensuales.
6. Comprueba las sumas de verificación
Las sumas de verificación sirven para detectar errores que pueden haberse introducido durante la transmisión o el almacenamiento de datos. Es importante comprobar las sumas de verificación de las dependencias de cada uno de tus proyectos. Suelen usarse para verificar la integridad de los datos y, aunque no deben considerarse una forma de verificar la autenticidad de tus dependencias, son una comprobación adicional útil. En Maven 4, las sumas de verificación de todas las dependencias se comprobarán de forma predeterminada. Hasta entonces, usa la opción -C en los comandos de Maven para habilitar la comprobación de sumas de verificación, que hará que falle la compilación si no coinciden.
7. No uses propiedades para las contraseñas
En Maven, es habitual usar propiedades como marcadores de posición en los archivos pom.xml. Puedes definir una propiedad, que llamaremos my.property, en el siguiente ejemplo de archivo pom.xml:
Ahora puedes hacer referencia a la propiedad my.property en cualquier parte de ese archivo pom.xml usando la notación ${my.property}. Aunque es una función muy útil, facilita mucho almacenar contraseñas para usarlas en otros lugares. Sin embargo, al hacerlo, almacenamos las contraseñas en texto sin formato y posiblemente las compartimos con todo el equipo. Se recomienda que los complementos usen las entradas de servidor de tu archivo settings.xml.
8. Usa desarrolladores y roles de Maven
Como mostró el informe sobre el estado de la seguridad del código abierto, es importante brindar a las personas la información que necesitan para reportar un problema de seguridad. Los repositorios de GitHub que incluyen un proceso para reportar vulnerabilidades de seguridad tienen más de tres veces más probabilidades de recibir reportes de errores de seguridad que los repositorios sin un proceso de divulgación documentado.
En el archivo pom.xml de Maven, puedes agregar una etiqueta developers con información de contacto de seguridad, para que cualquier persona sepa con quién comunicarse en tu equipo si encuentra un problema de seguridad. A continuación, puedes ver un ejemplo en el que agrego a Danny, nuestro especialista interno en seguridad.
Lo ideal es que la dirección de correo electrónico apunte a una dirección genérica como security@yourdomain.com. Así, si le pasa algo a la persona de contacto de seguridad, el correo seguirá llegando a una bandeja de entrada supervisada.
9. Mantente al día
Como siempre, las actualizaciones de seguridad llegan en las versiones más recientes, así que procura mantener Maven actualizado. Esto reducirá las probabilidades de usar una versión que contenga una falla de seguridad. En particular, evita Maven 3.0.4, ya que contiene un problema crítico de seguridad que ignora los certificados en las conexiones HTTPS. Para obtener la versión más reciente de Maven, visita la página de descargas de Maven.
10. Consulta los boletines de seguridad
El equipo de Maven te informa sobre los problemas de seguridad mediante boletines en el sitio de Apache Maven. Cuando el equipo de seguridad de Snyk encontró recientemente muchas instancias de la vulnerabilidad Zip Slip, el equipo de Apache (que trabajó arduamente con nosotros para eliminar las instancias de Zip Slip en los proyectos de Apache) publicó un boletín en el sitio de Apache Maven, como se muestra a continuación:
Asegúrate de suscribirte a la lista de correo announce@maven.apache.org y/o seguir a @ASFMavenProject en Twitter para enterarte de las últimas novedades del proyecto Apache Maven.
Con esto concluimos nuestras 10 prácticas recomendadas de seguridad para Apache Maven. Asegúrate de descargar esta guía práctica y colocarla en algún lugar visible para que siempre tengas presente la seguridad de tus compilaciones.
Asegúrate de imprimir la guía práctica y colocarla en algún lugar visible para recordar algunas de las prácticas recomendadas que debes seguir como desarrollador que usa Maven.
Comienza con Capture the Flag
Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.



