Guía rápida: 10 prácticas recomendadas de seguridad para Bitbucket

En esta guía rápida veremos cómo puedes mejorar tu seguridad como usuario o colaborador de Bitbucket. Algunos consejos son específicos de Bitbucket, pero muchos también sirven para otros repositorios Git y no Git.

Descargar guía rápida

Empecemos con nuestra lista de 10 prácticas recomendadas de seguridad para Bitbucket, comenzando por el error clásico de incluir contraseñas en los repositorios de Bitbucket.

1. Nunca guardes credenciales como código o configuración en Bitbucket

Hay muchas herramientas excelentes, como git-secrets, que pueden analizar tus commits de forma estática mediante un hook de Git previo al commit para asegurarse de que no intentes subir contraseñas ni información confidencial a tu repositorio de Bitbucket. Los commits se rechazan si la herramienta detecta alguno de los patrones de expresiones regulares configurados que indican que la información confidencial se almacenó de forma incorrecta. Esto puede ralentizar un poco las cargas, pero vale la pena.

Establecer reglas para todo el equipo que impidan guardar credenciales como código es una excelente manera de evitar malas prácticas dentro del flujo de trabajo de desarrollo existente. Usa una herramienta como Vault para administrar tus secretos en producción. Por último, considera usar una cadena de herramientas de administración de identidades y usuarios, como Keycloak (que actualmente mantiene un grupo de desarrolladores de Red Hat), entre otras.

Atlassian permite inyectar credenciales en los planes de Bitbucket mediante variables de entorno. Sin embargo, un enfoque más seguro podría ser usar ScriptRunner de Adaptavist como middleware para conectar sistemas de administración de credenciales y autenticación como Vault y Keycloak.

Hay muchas formas de evitar que las credenciales lleguen a tu repositorio desde el principio, y deberías implementar tantas como puedas. Sin embargo, siempre existe la posibilidad de que se filtre información confidencial. También deberías auditar tus repositorios con regularidad y usar herramientas como GitRob o truffleHog, que analizan tu base de código en busca de información confidencial mediante la coincidencia de patrones.

2. Elimina los datos confidenciales de tus archivos y del historial de Bitbucket

Si encuentras datos confidenciales en tu repositorio de Bitbucket, tendrás que hacer varias cosas para remediarlo. Primero, tendrás que invalidar los tokens y las contraseñas que quedaron expuestos. Una vez que un secreto se publica en Internet, debes asumir que los atacantes ya lo tienen y actuar en consecuencia.

Por supuesto, también tendrás que eliminar esos datos confidenciales de tu repositorio, pero no olvides que Bitbucket conserva un historial completo de todos tus commits. Esto incluye registros de cambios que contienen tu información confidencial. Es importante borrar el historial de Bitbucket cuando elimines datos confidenciales de un repositorio. Para obtener más información, consulta cómo purgar archivos del historial de tu repositorio. Aunque es un enlace de GitHub, son recomendaciones generales útiles para todos los repositorios Git, así que también puedes aplicarlas en Bitbucket. También puedes usar ScriptRunner para simplificar estas integraciones.

3. Controla estrictamente el acceso

Aquí en el Reino Unido, cuando hace mucho, mucho calor (es decir, cuando está templado), los británicos solemos abrir todas las ventanas de la casa para evitar que se convierta en un sauna. Sin embargo, cuando salimos, cerramos la puerta con doble llave, aunque a menudo dejamos varias ventanas entreabiertas para que circule el aire. Por supuesto, no tiene sentido: quien quiera entrar no intentará hacerlo por la puerta principal. Buscará una entrada menos evidente, quizá trepando por una de las ventanas que dejamos abiertas. A menudo adoptamos un enfoque similar para proteger nuestras aplicaciones. Nos concentramos mucho en los vectores de ataque más complejos, pero fallamos estrepitosamente frente a algunos de los más simples. Por ejemplo, basta con que un desarrollador deje su contraseña en una nota adhesiva pegada al monitor para que un atacante obtenga acceso. Debemos asegurarnos de seguir las prácticas y configuraciones básicas, tanto en la plataforma Bitbucket como en general. Exige a tus colaboradores que sigan estas prácticas básicas:

1. Exige la autenticación de dos factores en la cuenta de Bitbucket de cada colaborador.

2. Nunca permitas que los usuarios de Bitbucket compartan cuentas o contraseñas.

3. Las laptops y los dispositivos con acceso a tu código fuente deben estar protegidos correctamente.

4. Los administradores de los repositorios deben gestionar el acceso del equipo a los datos. Da a los colaboradores acceso solo a los datos que necesitan para hacer su trabajo.

5. Las cuentas de Bitbucket pueden ser personales y no desaparecen automáticamente cuando los usuarios dejan la empresa. Asegúrate de revocar diligentemente el acceso de los usuarios de Bitbucket que ya no trabajen contigo.

El modelo de permisos de ramas de Bitbucket te permite controlar quién puede subir commits a cada rama.

Puedes programar un trabajo de ScriptRunner para desactivar a determinados usuarios de Bitbucket en una fecha y hora específicas, e impedir que vuelvan a acceder a Bitbucket Server. En el ejemplo siguiente, desactivamos a User y Contractor el 17 de agosto de 2018 a las 9 a. m. En la sección Notes se incluye la clave de un problema de JIRA, ACCESS-1234, para identificar quién reportó el cambio.

4. Agrega un archivo SECURITY.md

Es natural que la mayoría de los propietarios y encargados de mantenimiento de proyectos agreguen un archivo README.md a su repositorio. De hecho, hoy en día se espera que esté presente y se considera una mala práctica omitirlo. Del mismo modo, cada vez es más común agregar un archivo SECURITY.md con información relacionada con la seguridad del proyecto. No solo brinda a los usuarios de tu proyecto de código abierto la información de seguridad importante que necesitan, sino que también hace que los encargados de mantenimiento piensen cómo gestionar las divulgaciones de seguridad, las actualizaciones y las prácticas generales de seguridad.

A continuación, presentamos una descripción general de algunos de los temas recomendados que deberías incluir en el archivo SECURITY.md:

Política de divulgación

El informe Estado de la seguridad del código abierto de Snyk de 2017 muestra que solo el 21 % de los encargados de mantenimiento que no tienen una política pública de divulgación recibió una notificación privada sobre una vulnerabilidad. La cifra aumenta al 73 % entre quienes sí tienen una política pública de divulgación. Esto demuestra la importancia de definir el procedimiento para que quien reporte un problema pueda divulgar vulnerabilidades de forma responsable. Debe incluir a quién contactar y cómo hacerlo. Esto es muy importante, ya que te permite recibir comentarios valiosos de los usuarios de tu proyecto. Si no hay una forma sencilla y bien definida de hacer algo, es fácil que no nos molestemos en hacerlo. Otras personas podrían registrar la existencia de una vulnerabilidad como un problema público, haciendo que el mundo se entere antes de que haya una solución disponible. Asegúrate de dar a los usuarios de tu proyecto todas las indicaciones necesarias para que proporcionen la información adecuada a los encargados de mantenimiento cuando encuentren problemas.

Política de actualizaciones de seguridad

Todos los días se descubren vulnerabilidades de software. Cuando se encuentra una vulnerabilidad en tu aplicación o biblioteca, tienes la responsabilidad de informar a los usuarios de tu proyecto. Es posible que estén usando tu código de código abierto en producción, en sistemas críticos. Necesitas un proceso bien definido para compartir la información pertinente, incluida la gravedad de la vulnerabilidad, el riesgo que implica y cómo actualizar a una versión corregida de tu código. Define este proceso con anticipación para que la información llegue a los usuarios de tu proyecto y puedan enterarse lo antes posible de las nuevas vulnerabilidades de seguridad a medida que se detectan y corrigen. Algo tan sencillo como una lista de correo de seguridad puede ser suficiente. El archivo SECURITY.md es un buen lugar para incluir esta información en el repositorio. Si tienes un sitio web, considera crear una página independiente; consulta como ejemplo la página de seguridad de Express.js.

Configuración relacionada con la seguridad

Las consideraciones de seguridad de tu proyecto van más allá del código. Es probable que los usuarios de tu proyecto de código abierto deban agregar configuración y crear ajustes para que funcione correctamente en su entorno. Deberías recomendarles configuraciones que refuercen la seguridad al implementar el proyecto. Por ejemplo, activar HTTPS, agregar una capa de autorización y, por supuesto, reemplazar las contraseñas predeterminadas (una recomendación que muchos usuarios de MongoDB desearían haber recibido). Recuerda que muchos usuarios suelen tener conocimientos de seguridad bastante limitados, así que cualquier consejo que puedas compartir les será de gran ayuda.

Brechas de seguridad conocidas y mejoras futuras

Existe un equilibrio entre brindar a los usuarios la información que necesitan para proteger su entorno y facilitar a un atacante posibles rutas de ataque. Considera siempre cómo podrían usar la información que compartes ambas partes. Es muy raro que un proyecto haya implementado todas las mejoras de seguridad que tiene previstas. Es importante informar a los usuarios de tu proyecto sobre los controles de seguridad que aún no están implementados. Tus usuarios merecen conocer toda la información para tomar decisiones fundamentadas sobre cómo usar tu proyecto. Quién sabe: ¡quizá incluso recibas contribuciones de tus usuarios para implementar alguno de los controles de seguridad de la lista!

5. Recibe consejos de seguridad en tu flujo de trabajo con Code Insights

Code Insights está diseñado para mostrar información relevante para un pull request, de modo que quienes lo crean y lo revisan puedan tomar decisiones mejor fundamentadas. Snyk ofrece una integración que analiza todos los pull requests abiertos para comprobar que no introduzcan nuevas vulnerabilidades de código abierto y puede impedir que se fusionen cuando contienen vulnerabilidades nuevas.

Si se encuentra una nueva vulnerabilidad, Snyk te avisa y abre un pull request de corrección, con sugerencias de actualización o parches de Snyk para solucionarla.

En la interfaz de pull requests de Bitbucket, se analizan los cambios y los resultados se muestran en anotaciones detalladas en línea, junto a los cambios que introducen nuevos problemas. Estas anotaciones facilitan la comprensión de los resultados del análisis de Snyk y permiten tomar decisiones fundamentadas.

Para obtener más información sobre la instalación y el uso, consulta esta publicación del blog de Snyk sobre Bitbucket Code Insights, que incluye un video de todo el proceso.

6. Valida cuidadosamente tus aplicaciones de Bitbucket

Todas las buenas plataformas se pueden ampliar, y Bitbucket no es la excepción gracias a su marketplace de aplicaciones. Las organizaciones y los desarrolladores externos crean aplicaciones, así que ten esto en cuenta cuando las agregues a tu repositorio. Considera lo siguiente al elegir e instalar aplicaciones de Bitbucket:

• No concedas a las aplicaciones más permisos de acceso de los que necesitan.

• Pregúntate por qué una aplicación requiere el nivel de acceso que solicita y piensa en el daño que podría causar con esos permisos.

• Antes de permitir que accedan a tus repositorios, valida que la persona autora o la organización responsable de la aplicación sean legítimas y confiables, tal como lo harías al incorporar a un nuevo colaborador a tu proyecto.

Tu seguridad depende de la parte más débil de la cadena. Si una aplicación a la que das acceso tiene una postura de seguridad deficiente, una vulneración de su código permitirá a los atacantes acceder al tuyo, uno de tus activos más confidenciales.

Por último, asegúrate de supervisar o auditar tus aplicaciones y a sus colaboradores con regularidad para confirmar que aún las necesitas, que sigues confiando en ellas y que consideras justificados los permisos que requieren. Mantén al día la administración de aplicaciones y elimina las que ya no necesites o que requieran permisos que no quieras conceder.

7. Agrega pruebas de seguridad a los pull requests

Bitbucket cuenta con un potente framework de Git Hooks basado en eventos que te permite enviar solicitudes HTTP POST a un servicio de tu elección cuando se generan eventos. Hay una gran cantidad de eventos entre los que puedes elegir, pero uno de los más útiles para probar cambios incrementales en el código es el evento pull_request. Muchas herramientas de análisis estático de código son compatibles con Git Hooks, de modo que, cuando se crea un PR, se envía una solicitud HTTP POST para que prueben las actualizaciones más recientes. Este es un buen momento para asegurarte de que los cambios en el código y la configuración estén alineados con tus expectativas de seguridad.

Snyk, por ejemplo, analiza estáticamente tu repositorio para encontrar dependencias vulnerables que podrías estar usando y te ayuda a corregirlas. Puedes probar tus repositorios desde la interfaz de Snyk para encontrar problemas y también evitar que los desarrolladores agreguen nuevas bibliotecas vulnerables: basta con probar los pull requests y hacer que la prueba falle si se introduce una vulnerabilidad nueva.

Además de la conveniente integración con Bitbucket, los pull requests son mejores que “romper la compilación” porque no tienen que bloquear una fusión (de hecho, son informativos de forma predeterminada) y permiten probar tus cambios, no solo el resultado (por ejemplo, fallar únicamente si introdujiste una biblioteca vulnerable, no si ya había una).

Además de Snyk, también deberías considerar usar SonarCloud o CodeClimate para realizar revisiones automatizadas de seguridad del código. También puedes agregar un script de ScriptRunner para asegurarte de no subir secretos a tu repositorio.

8. Agrega pruebas de seguridad en tus pipes de Bitbucket

Bitbucket Pipes te permite personalizar y automatizar un flujo de trabajo de CI/CD a partir de un grupo de tareas listas para usar. Snyk ofrece un pipe listo para usar que analiza las dependencias de tu aplicación y las imágenes de Docker para detectar vulnerabilidades de seguridad conocidas en código abierto, como parte del flujo de integración continua y entrega continua (CI/CD).

Para agregar el pipe de Snyk a tu flujo de trabajo, solo tienes que copiarlo y pegarlo en el pipeline.

Una vez agregado al flujo de trabajo de Bitbucket Pipeline, el pipe de Snyk analiza tus dependencias para detectar vulnerabilidades de código abierto como parte del flujo de CI/CD. Si encuentra vulnerabilidades, el pipe de Snyk controla el proceso según la configuración que hayas definido. Por ejemplo, puede impedir que las vulnerabilidades de gravedad alta avancen en la compilación. Para obtener más información, consulta la documentación.

Otro pipe que deberías considerar incluir en tu pipeline para mejorar tu resiliencia de seguridad es SonarCloud.

9. Elige la opción de Bitbucket adecuada para tus necesidades de seguridad

Según las regulaciones de tu proyecto o de tu organización, es posible que solo puedas usar software que se ejecute localmente. O quizás haya restricciones sobre dónde se almacena tu código fuente o qué otras organizaciones pueden acceder a él. Esta es una restricción común en instituciones financieras, organismos gubernamentales y otros sectores con regulaciones estrictas. Sin embargo, ¡eso no significa que no puedas usar Bitbucket!

Echa un vistazo a la opción Bitbucket Server completamente local, que te permite alojar repositorios de Bitbucket dentro de tu organización. Esto significa que puedes desconectarte de Internet y aun así tener acceso interno a tus proyectos en los repositorios de Bitbucket Server.

10. Rota las claves SSH y los tokens de acceso personal

El acceso a Bitbucket suele realizarse mediante claves SSH o tokens de usuario personales (en lugar de una contraseña, ¡porque habilitaste la autenticación de dos factores!). Pero ¿qué pasa si roban esos tokens y no te enteras? Asegúrate de renovar periódicamente tus claves y tokens para mitigar cualquier daño causado por claves que se hayan filtrado.

Para obtener más información sobre la seguridad de Bitbucket, asegúrate de leer también los avisos de seguridad de Bitbucket. Y si todavía no lo hiciste, descarga esta hoja de referencia ahora y tenla a mano para que tus decisiones futuras sean seguras.