10 prácticas recomendadas de seguridad para GitHub

En el panorama digital actual, que avanza rápidamente y está dominado por el código, proteger tu base de código es fundamental. GitHub es la plataforma preferida de la comunidad de desarrollo para compartir código y controlar versiones. Sin embargo, debido a su amplia adopción, GitHub no está exento de muchos de los desafíos de seguridad que enfrentan los desarrolladores a diario. Desde el acceso no autorizado hasta el riesgo de filtraciones de datos confidenciales, es vital que los desarrolladores apliquen las prácticas recomendadas de seguridad para GitHub a fin de proteger su código y sus flujos de trabajo de desarrollo.

En esta guía rápida, analizaremos diez prácticas recomendadas que puedes implementar para mejorar la seguridad de GitHub. Descarga la hoja de una página y sigue leyendo para conocer una explicación más detallada de las diez acciones seleccionadas.

Habilita y exige la autenticación de dos factores en GitHub

La autenticación de dos factores, que suele abreviarse como 2FA, es un protocolo de seguridad que exige que los usuarios proporcionen dos factores de autenticación diferentes para verificar su identidad. Por lo general, esto incluye algo que sabes (como una contraseña) y algo que tienes (como un teléfono). Este enfoque de varias capas dificulta mucho más que una persona no autorizada acceda a tus datos, por lo que es una herramienta fundamental para AppSec y la seguridad del código.

GitHub es una fuente inagotable de propiedad intelectual y código confidencial. Como desarrolladores y profesionales de DevOps, es de suma importancia proteger nuestros repositorios de código y la integridad de los proyectos de código abierto en los que trabajamos. La 2FA agrega una capa adicional de seguridad, lo que dificulta que posibles atacantes obtengan acceso no autorizado, incluso si logran conseguir tu contraseña.

Para habilitar la 2FA en GitHub, sigue estos sencillos pasos:

1. Inicia sesión en tu cuenta de GitHub.

2. Haz clic en tu foto de perfil, en la esquina superior derecha, y luego haz clic en Configuración.

3. En la barra lateral, haz clic en Seguridad.

4. Haz clic en el botón Habilitar la autenticación de dos factores.

5. Elige si quieres usar una aplicación de autenticación o recibir mensajes de texto para la 2FA y sigue las instrucciones para configurarla.

6. Por último, recibirás algunos códigos de recuperación. Son importantes por si pierdes el acceso a tu método de 2FA, así que asegúrate de guardarlos en un lugar seguro.

Hacer que la autenticación de dos factores (2FA) sea obligatoria para los repositorios de GitHub de tu organización es un paso fundamental para mejorar la seguridad. Al exigir la 2FA, cada integrante del equipo que acceda al repositorio debe proporcionar una verificación adicional, como un código temporal de una aplicación de autenticación o enviado por SMS. Esta medida de seguridad adicional reduce significativamente el riesgo de acceso no autorizado, especialmente si las contraseñas se ven comprometidas. Exigir la 2FA protege tu base de código y demuestra un compromiso proactivo con el mantenimiento de un entorno de desarrollo seguro, en línea con las prácticas recomendadas para un control de acceso sólido.

Limita el acceso a los repositorios

En el ámbito de la seguridad de las aplicaciones y del código, es esencial limitar el acceso a tus repositorios de GitHub. Es una forma eficaz de controlar quién puede ver, editar o administrar tu código fuente. Esta práctica no solo ayuda a mantener la integridad del código, sino que también lo protege de posibles amenazas de seguridad.

El principio de privilegio mínimo (PoLP) es un concepto de seguridad informática según el cual cada usuario recibe el nivel mínimo de acceso necesario para cumplir sus funciones laborales. Este principio también debe aplicarse a tus repositorios de GitHub.

Aplicar el PoLP a tus repositorios ayuda a reducir los riesgos relacionados con lo siguiente:

• Exposición accidental de datos confidenciales: restringir el acceso reduce las posibilidades de que se envíen accidentalmente datos confidenciales a un repositorio, ya que menos personas tienen permiso de escritura.

• Ataques maliciosos: al limitar el acceso a tu base de código, reduces la cantidad de puntos de entrada para posibles atacantes.

• Cambios no deseados: si menos personas tienen acceso de escritura o administración, hay menos posibilidades de que se realicen cambios involuntarios en el código que provoquen errores o compilaciones fallidas.

GitHub ofrece varios niveles de acceso de usuario para los repositorios: Read, Triage, Write, Maintain y Admin. Cada nivel de acceso otorga distintas capacidades al usuario. Por ejemplo, un usuario con permisos Read solo puede ver y bifurcar el repositorio, mientras que un usuario con permisos Admin puede administrar la configuración, los equipos y las integraciones del repositorio.

Recuerda: siempre otorga a cada colaborador el menor nivel de acceso que necesite para cumplir su función. Si hace falta, siempre puedes aumentar su nivel de acceso más adelante.

Evita almacenar credenciales como código o configuración en GitHub

Almacenar credenciales directamente en repositorios de GitHub supone un riesgo de seguridad considerable, ya que expone información confidencial a posibles accesos no autorizados. Para reducir este riesgo, los desarrolladores deben usar alternativas seguras para almacenar información confidencial, como variables de entorno o archivos de configuración fuera del repositorio con control de versiones. Al hacer referencia a estas variables o archivos externos en el código, en vez de incluir las credenciales directamente, los desarrolladores mantienen una separación clara entre los datos confidenciales y la base de código de acceso público, lo que reduce el riesgo de exposición involuntaria.

Durante el desarrollo, Snyk Code puede ayudar a identificar credenciales y secretos codificados directamente en el código. El complemento de Snyk Code para IDE es una gran herramienta para detectar posibles problemas de seguridad antes de confirmar los cambios en el código.

Además, las herramientas especializadas como GitLeaks y Git-secrets son esenciales para mejorar la seguridad. GitLeaks analiza los repositorios en busca de secretos y claves de API, y envía alertas inmediatas cuando detecta información que podría comprometer la seguridad. Integrar GitLeaks en los pipelines de CI/CD o en los hooks previos a la confirmación permite corregir rápidamente los problemas. Git-secrets, otra herramienta valiosa, evita la inclusión accidental de secretos al analizar las confirmaciones, ramas y archivos preparados para detectar patrones predefinidos de datos confidenciales. Al configurarse para rechazar confirmaciones que contengan patrones identificados, Git-secrets ofrece una defensa sólida contra las filtraciones involuntarias y refuerza las medidas de seguridad en los repositorios de Git y GitHub.

La combinación de estas herramientas con tu flujo de trabajo de desarrollo mejora la identificación y mitigación proactivas de los riesgos de seguridad asociados con el almacenamiento de credenciales en repositorios de Git y GitHub. Gracias a los análisis periódicos y las comprobaciones automatizadas, los equipos pueden reducir significativamente la probabilidad de exponer información confidencial y fortalecer su base de código frente a posibles amenazas de seguridad.

Si se detecta un secreto, evalúa rápidamente la situación e identifica las áreas afectadas del repositorio. Elimina o reemplaza las credenciales comprometidas, cambia las claves o contraseñas asociadas e informa del incidente a los integrantes del equipo. Además, si invalidar o reemplazar los datos no es suficiente, puedes considerar eliminarlos reescribiendo el historial de Git con una herramienta como BFG Repo-Cleaner. Ten en cuenta que este historial puede haberse copiado en equipos locales o bifurcaciones de tu repositorio.

Conecta tus repositorios a Snyk y analiza si tienen vulnerabilidades

Una de las mejores prácticas de AppSec y seguridad del código es conectar tus repositorios de GitHub a Snyk, una herramienta líder de seguridad para desarrolladores. Esta integración te permite analizar automáticamente si hay vulnerabilidades en tu base de código, imágenes de contenedor, dependencias de código abierto y configuraciones de infraestructura como código.

Conectar tu repositorio de GitHub a tu cuenta de Snyk es muy sencillo. Primero, inicia sesión en tu cuenta de Snyk y ve a la página de Integraciones. Haz clic en la integración de GitHub y sigue los pasos para autorizar a Snyk a acceder a tus repositorios de GitHub.

De forma predeterminada, Snyk ofrece cuatro tipos de análisis para tus repositorios de GitHub:

1. Snyk Open Source: este análisis comprueba si tus dependencias de código abierto tienen vulnerabilidades conocidas. Es una herramienta esencial para la seguridad del código abierto, ya que te ayuda a encontrar y corregir problemas en tus paquetes de terceros. Snyk también puede comprobar las licencias de las dependencias utilizadas, lo que te ayuda a tomar las decisiones correctas para cumplir con los requisitos de las licencias.

2. Snyk Code: este análisis comprueba si tu base de código tiene vulnerabilidades de seguridad y problemas de calidad del código. Ayuda a proteger las aplicaciones al identificar posibles fallas de seguridad en tu código.

3. Snyk Container: este análisis comprueba si tus imágenes de contenedor de Docker tienen vulnerabilidades. Es una parte fundamental de la seguridad de los contenedores, ya que garantiza que tus imágenes de Docker sean seguras para implementar.

4. Snyk IaC: este análisis comprueba tus configuraciones de infraestructura como código. Ofrece monitoreo y corrección continuos para identificar y corregir vulnerabilidades en las configuraciones de infraestructura en la nube, como Kubernetes, Terraform y CloudFormation, entre otras.

Analiza los pull request entrantes

Además de conectar tus repositorios de GitHub a Snyk para realizar análisis exhaustivos de vulnerabilidades, es fundamental aprovechar la capacidad de la plataforma para analizar en tiempo real los nuevos pull request (PR). La función de análisis de pull request de Snyk te permite identificar y abordar de forma proactiva las vulnerabilidades de seguridad que se introducen durante el desarrollo. Cuando los desarrolladores proponen cambios en sus PR, Snyk analiza automáticamente la base de código modificada, las dependencias de código abierto y las imágenes de contenedor, y destaca posibles vulnerabilidades antes de que el código se combine con la rama predeterminada.

Este enfoque proactivo permite que los equipos de desarrollo corrijan los problemas de seguridad en las primeras etapas del ciclo de vida del desarrollo y reduce el riesgo de introducir vulnerabilidades en el entorno de producción.

Al integrar Snyk sin complicaciones en tu flujo de trabajo de GitHub, mejoras la seguridad de tu base de código y fomentas una cultura de DevSecOps que prioriza la seguridad continua durante todo el proceso de desarrollo de software. Conectar tus repositorios a Snyk y habilitar el análisis de pull request agrega una capa adicional de defensa y garantiza que solo se combine código seguro con tu rama predeterminada.

Agrega un archivo SECURITY.md

Además del archivo README.md, integrar un archivo SECURITY.md es un paso fundamental para mejorar la postura de seguridad de tu proyecto. Este archivo específico funciona como un centro de información de seguridad importante, garantiza la transparencia y ofrece instrucciones claras a los colaboradores y las partes interesadas.

Política de divulgación

Establece un procedimiento claro para las personas que descubran problemas de seguridad y designa un punto de contacto, que suele configurarse como el correo electrónico “security@”. Esta política fomenta la divulgación responsable, permite que personas externas informen de forma segura sus inquietudes de seguridad y promueve un enfoque colaborativo para gestionar las vulnerabilidades.

Política de actualizaciones de seguridad

Describe cómo planea el proyecto difundir información sobre las vulnerabilidades de seguridad recién identificadas. Esto incluye los canales por los que los usuarios recibirán notificaciones y los pasos que deben seguir para resolver estos problemas rápidamente. Una política de actualizaciones bien definida garantiza que los usuarios estén informados y puedan tomar las medidas necesarias para proteger sus implementaciones.

Configuración relacionada con la seguridad

Destaca los ajustes que los usuarios deben tener en cuenta para influir en la postura de seguridad al implementar el proyecto. Esta sección sirve como guía práctica para configurar las medidas de seguridad y garantiza que los usuarios conozcan las opciones disponibles para mejorar la seguridad general de sus implementaciones.

Brechas de seguridad conocidas y mejoras futuras

Comunica con transparencia las brechas de seguridad existentes que se reconocen, pero que aún no se han resuelto. Además, comparte información sobre las mejoras de seguridad futuras que se están considerando, pero que todavía no se han implementado. Esto fomenta una cultura de transparencia y colaboración, e invita a los colaboradores a participar activamente en la mejora de la seguridad del proyecto.

El archivo SECURITY.md desempeña un papel fundamental para establecer un entorno seguro y abierto para tu proyecto. No solo sienta las bases para adoptar prácticas de seguridad responsables, sino que también es un recurso valioso para colaboradores y usuarios, lo que contribuye, en última instancia, a un ecosistema de proyectos más resiliente y seguro.

Usa reglas de protección de ramas

Las reglas de protección de ramas aportan una capa esencial de seguridad a los flujos de trabajo DevSecOps, ya que impiden cambios no autorizados o accidentales en partes sensibles de tu base de código. En esta sección, exploraremos qué son las reglas de protección de ramas y cómo configurarlas en GitHub para reforzar la seguridad de tu base de código.

Las reglas de protección de ramas de GitHub son un conjunto de controles que los administradores de repositorios pueden configurar para garantizar la calidad del código y gestionar la colaboración. Te permiten configurar y hacer cumplir exactamente cómo se deben fusionar los cambios de código en una rama. Este es un aspecto fundamental de la seguridad de las aplicaciones y del código, ya que aplica el principio de privilegio mínimo y garantiza que solo los usuarios autorizados puedan hacer cambios en la base de código.

Algunos de los controles que puedes aplicar con las reglas de protección de ramas son:

• Exigir revisiones de pull request antes de fusionar: Así te aseguras de que al menos otra persona revise y apruebe los cambios antes de que se puedan fusionar en una rama protegida.

• Exigir que se aprueben las comprobaciones de estado antes de fusionar: Esto permite asegurarte de que se aprueben todas las pruebas de CI requeridas antes de fusionar el código.

• Restringir quién puede hacer push a las ramas que coincidan: Esto te permite especificar qué usuarios o equipos pueden hacer push a una rama protegida y 

• Exigir un historial lineal de commits: Así te aseguras de que el historial de commits sea claro y fácil de entender.

Pasos para configurar reglas de protección de ramas

Sigue estos pasos para configurar reglas de protección de ramas en GitHub:

1. Ve a tu repositorio de GitHub y abre la pestaña Settings.

2. En la barra lateral izquierda, haz clic en Branches.

3. En Branch protection rules, haz clic en Add rule.

4. En el campo Branch name pattern, ingresa el nombre de la rama que quieres proteger.

5. En Protect matching branches, selecciona los requisitos que quieres aplicar. Puedes elegir entre las opciones mencionadas anteriormente.

6. Haz clic en Create para guardar la nueva regla de protección de ramas.

El uso eficaz de las reglas de protección de ramas puede mejorar considerablemente la seguridad y la confiabilidad de tu base de código. En la mayoría de los repositorios que se usan en Snyk, no puedes hacer push directamente a la rama principal por motivos de seguridad y debes usar un PR. Esto se hace cumplir mediante la implementación de reglas de protección de ramas.

Rota los tokens SSH y las claves personales

Rotar periódicamente los tokens SSH y las claves personales es una práctica esencial para reforzar la seguridad del código en tus repositorios de GitHub. En esta sección, te explicaremos cómo hacerlo y por qué es importante para la seguridad de las aplicaciones, la seguridad de los contenedores y DevSecOps.

Rotar los tokens SSH y las claves personales es una medida de seguridad proactiva que ayuda a prevenir el acceso no autorizado a tus repositorios de GitHub. Si un actor malicioso logra obtener tu token SSH o tus claves personales, puede causar estragos en tu base de código. Rotar estas credenciales periódicamente dificulta que los atacantes mantengan el acceso a tus repositorios y refuerza la seguridad del código abierto.

Cómo rotar los tokens SSH y las claves personales

GitHub ofrece un proceso sencillo para rotar tokens SSH y claves personales. Sigue estos pasos:

1. Inicia sesión en tu cuenta de GitHub.

2. Ve a Settings, Developer settings y luego a Personal access tokens.

3. Haz clic en Generate new token.

4. Asigna una descripción al token y selecciona los alcances (o permisos) que quieres otorgarle.

5. Haz clic en Generate token.

Después de generar un token nuevo, asegúrate de reemplazar el anterior en todos los lugares donde se use.

Automatiza la rotación de tokens y claves

Para los equipos con numerosos repositorios o entornos DevOps grandes, rotar manualmente los tokens SSH y las claves puede ser una tarea abrumadora. Automatizar este proceso garantiza la consistencia y ahorra tiempo. Puedes aprovechar GitHub Actions o las herramientas de tu canalización de CI/CD, como Jenkins, para automatizar la rotación.

En conclusión, rotar los tokens SSH y las claves personales es una práctica esencial para mantener la seguridad de tus repositorios de GitHub. Recuerda que el objetivo no es complicarte la vida, sino asegurar que tu código esté protegido y libre de accesos no autorizados.

Actualiza las dependencias automáticamente

Mantener una base de código actualizada y segura es fundamental para la seguridad de las aplicaciones, del código y de los contenedores, así como para DevSecOps. Un aspecto clave es actualizar las dependencias periódicamente. A menudo se encuentran vulnerabilidades de seguridad en bibliotecas de terceros desactualizadas. Por eso, es importante contar con una estrategia para actualizar las dependencias automáticamente y minimizar el riesgo de brechas de seguridad. En esta sección, analizaremos la importancia de actualizar bibliotecas de terceros y cómo usar herramientas como Snyk para automatizar este proceso.

Las bibliotecas de terceros son una parte integral del desarrollo de software, ya que permiten a los desarrolladores reutilizar el código de otros y evitar reinventar la rueda. Sin embargo, si no se gestionan correctamente, estas bibliotecas pueden convertirse en un eslabón débil de tu cadena de seguridad. Pueden quedar desactualizadas y representar riesgos de seguridad graves si contienen vulnerabilidades que no se han corregido en las versiones más recientes.

Actualizar las dependencias manualmente puede ser una tarea abrumadora y llevar mucho tiempo, sobre todo en proyectos grandes. Aquí es donde entra en juego la automatización.

Automatiza las actualizaciones de dependencias con Snyk

Snyk es una herramienta potente que ayuda a identificar y corregir vulnerabilidades en tus dependencias. Además de analizar vulnerabilidades, Snyk también puede automatizar el proceso de actualización de tus dependencias.

Al integrarse con GitHub, Snyk analiza tus repositorios para detectar dependencias desactualizadas y versiones vulnerables de bibliotecas. Luego, abre pull requests (PRs) en GitHub con actualizaciones para esas dependencias, lo que te permite revisar y fusionar los cambios de forma sencilla.

Después de conectar GitHub con tu cuenta de Snyk, asegúrate de que la opción Automatic dependency upgrade pull requests esté habilitada en Integration Settings at the Organization level or in the Project Settings.

Ahora, Snyk supervisará tus repositorios y creará PRs para las dependencias desactualizadas, lo que te facilitará mantener tu base de código segura y actualizada.

En conclusión, automatizar las actualizaciones de dependencias es una práctica recomendada que todos los desarrolladores y profesionales de DevOps deberían adoptar. No solo mejora la seguridad de tus aplicaciones, sino que también ahorra tiempo y esfuerzo a largo plazo. Si aprovechas herramientas como Snyk, puedes anticiparte a las vulnerabilidades de seguridad en bibliotecas de terceros y mantener una base de código segura y en buen estado.

Usa repositorios privados para los datos confidenciales

Es esencial saber cómo gestionar datos confidenciales en plataformas como GitHub. Una de las formas más sencillas de protegerlos es usar repositorios privados. En esta sección, explicaremos la diferencia entre los repositorios públicos y privados, y cuándo conviene usar repositorios privados.

GitHub ofrece dos tipos de repositorios: públicos y privados:

1. Repositorios públicos: Como su nombre indica, estos repositorios son visibles para todos. Cualquier usuario de GitHub puede ver, clonar y bifurcar un repositorio público. Sin embargo, solo los colaboradores del repositorio pueden hacer push de cambios. Esta apertura fomenta la colaboración y el desarrollo de código abierto.

2. Repositorios privados: Solo el propietario del repositorio y los colaboradores que haya agregado explícitamente pueden ver los repositorios privados. Aunque alguien tenga la URL de un repositorio privado, no podrá ver su contenido sin los permisos necesarios.

Cuándo usar repositorios privados

Aunque los repositorios públicos pueden ser excelentes para proyectos de código abierto y el desarrollo colaborativo, no son adecuados para datos confidenciales. Estos son algunos casos en los que conviene usar repositorios privados:

1. Protección de datos confidenciales: Si tu base de código contiene datos confidenciales, como claves de API, contraseñas u otra información privada, debes almacenarla en un repositorio privado. Así te aseguras de que solo los colaboradores autorizados tengan acceso a esos datos.

2. Código propietario: Si tu base de código es propietaria y no debería estar disponible públicamente, lo mejor es usar un repositorio privado. Esto suele aplicarse a las aplicaciones empresariales y a los productos de software prémium.

3. Etapa de desarrollo: Si tu proyecto está en sus primeras etapas de desarrollo y aún no está listo para mostrarse públicamente, lo mejor es mantenerlo en un repositorio privado. Así puedes controlar quién tiene acceso al proyecto durante su desarrollo.

Deshabilita la creación de repositorios públicos

Para mejorar la seguridad y proteger la información confidencial, las organizaciones que no necesitan repositorios públicos deberían considerar deshabilitar por completo el acceso público. Esta medida proactiva ayuda a evitar la creación accidental de repositorios de acceso público y reduce el riesgo de exposición de datos. Al aplicar la configuración de repositorios privados desde Your Organizations, Settings y luego Member Privileges, las organizaciones se aseguran de que solo los usuarios autorizados puedan acceder a los repositorios. Esto no solo se ajusta a las prácticas recomendadas de protección de datos, sino que también simplifica la gestión de repositorios y promueve un entorno más seguro y controlado para el código de la organización.

En conclusión, usar repositorios privados para los datos confidenciales es una práctica recomendada fundamental para la seguridad en GitHub. Ayuda a proteger los datos confidenciales y el código propietario, y refuerza la seguridad del código y las prácticas de DevSecOps. 

Elige con cuidado tus aplicaciones de GitHub

A la hora de elegir aplicaciones de GitHub, es esencial tomar decisiones bien pensadas. Estas aplicaciones, desarrolladas por distintas entidades, ofrecen excelentes funciones, pero antes de empezar a usarlas, ten en cuenta algunos aspectos importantes:

• Revisa los permisos: Evita la tentación de otorgar permisos sin restricciones. Concede solo los que sean absolutamente necesarios. Limitar el acceso reduce los riesgos innecesarios.

• Cuestiona los accesos: Si se solicitan permisos amplios, analiza rigurosamente si son necesarios. Evalúa las posibles consecuencias si las cosas salen mal. Se trata de gestionar el riesgo con criterio.

• Quién está detrás: Antes de incorporar una aplicación a tu entorno de desarrollo, investiga a fondo. Verifica la legitimidad de sus creadores. Piénsalo como si estuvieras evaluando a un nuevo integrante del equipo: la confianza es fundamental.

• Revisa la seguridad: Considera la seguridad de una aplicación como la primera línea de defensa de tu código. Cualquier falla podría dejarlo vulnerable. Examina sus protocolos de seguridad para asegurarte de que ofrezcan una protección sólida.

• Revísalas periódicamente: El mantenimiento periódico es indispensable. Evalúa cada cierto tiempo si tus aplicaciones siguen siendo necesarias y confiables. Piensa en ello como mantener el orden en tu entorno de código.

Recuerda que la seguridad de tu código es un asunto serio. Mantente alerta, toma decisiones bien fundamentadas y protege la estabilidad y la seguridad de tu aplicación.

Conclusión

En conclusión, hemos explorado el papel fundamental que desempeña GitHub en el desarrollo de software moderno y la importancia de aplicar prácticas recomendadas de seguridad sólidas. Las diez pautas que hemos analizado ofrecen una base sólida para proteger tus repositorios y proyectos de GitHub. Cada práctica complementa a las demás para crear una defensa robusta contra diversas amenazas y vulnerabilidades. 

A todos los desarrolladores y profesionales de DevOps, les recomendamos adoptar estas prácticas recomendadas de seguridad. La seguridad no es responsabilidad de un solo equipo o persona, sino un compromiso colectivo que abarca todos los aspectos del desarrollo y las operaciones de software. 

Como solemos decir en DevSecOps: «Todos somos responsables de la seguridad». Aportemos todos nuestro esfuerzo para que nuestras aplicaciones, nuestros datos y nuestros usuarios estén lo más protegidos posible. 

Con el espíritu de aprendizaje continuo, mantente siempre abierto a nuevas prácticas, herramientas y procesos que puedan mejorar aún más la seguridad de tu entorno de GitHub.

¡Que disfrutes programar y mantente seguro!