El plan del nuevo jefe de Seguridad de GitHub para evitar que los desarrolladores sigan filtrando secretos y contraseñas de empresas accidentalmente

GitHub es el mayor repositorio de código abierto de toda la red, y más de 50 millones de desarrolladores lo utilizan. Eso hace que algo de información que debió seguir siendo privada esté en la herramienta y de forma pública.

Y a veces, estas filtraciones han tenido consecuencias desastrosas.

Este gráfico revela cómo las mafias de 'ransomware' aprovecharon la pandemia para multiplicar sus ataques contra empresas, hospitales y administraciones

Tras el hackeo masivo que tuvo lugar el año pasado contra SolarWinds, los investigadores descubrieron que un código público disponible en GitHub incluía una contraseña sin encriptar y en texto plano para administradores de la firma, "solarwinds123". El CEO de SolarWinds, Sudhakar Ramakrishna, culpó a un becario de ello.

A la luz de los recientes descubrimientos sobre cómo GitHub fue clave en estos agujeros de seguridad, la propia compañía trabaja ahora en software y herramientas, así como en formaciones para ayudar a prevenir que los desarrolladores faciliten accidentalmente que los secretos de sus empresas se conozcan a través de los repositorios de sus códigos. Así lo explica Mike Hanley, el nuevo responsable de Seguridad o CSO de la firma.

"Tenemos la obligación de seguir protegiendo la plataforma que es la casa de muchos desarrolladores", incide Hanley. "Creo de verdad que estamos viendo un interesante cambio de tendencia en el que nos aseguramos de que el despliegue de tecnología tiene la seguridad por defecto como valor de diseño".

Como el primer CSO de GitHub que crea su propio equipo de seguridad, Hanley apunta que pondrá el foco en mejorar las herramientas de la plataforma que escanean código, desplegadas por primera vez en 2018. Las herramientas analizan automáticamente el código que suben los usuarios para marcar si hay contraseñas o datos de terceros proveedores como Amazon Web Services o Google Cloud para avisar a los desarrolladores.

La idea es marcar así automáticamente estos deslices para que los desarrolladores los puedan eliminar antes de que caigan en manos de ciberdelincuentes. El investigador en ciberseguridad Andrzej Dyjak comprobó recientemente cómo funcionan estas herramientas de GitHub trasladando una contraseña de AWS a un repositorio público. Siete minutos después de esta acción, GitHub le alertó automáticamente de que había una contraseña pública en su repositorio. Cuatro minutos después recibió otro aviso: un bot malicioso estaba intentando usar esa contraseña para comprometer su servidor.

El objetivo de Hanley es que GitHub siga invirtiendo en estos escáneres secretos para hacer más sencillo a los desarrolladores el protegerse ante filtraciones no deseadas y sin sacrificar agilidad.

"Este es un desafío clásico de usabilidad e ingenieros que solo intentan hacer su trabajo", considera.

GitHub pide atención después de que un investigador hackeara a Apple, Tesla o Microsoft usando claves de sus repositorios públicos

Hanley destaca que GitHub también está formando a desarrolladores sobre nuevos tipos de vulnerabilidades que tienen similitudes con estas filtraciones no deseadas.

Un hacker ético llamado Alex Birsan desveló el pasado mes de febrero que fue capaz de hackear a Apple, Tesla, Netflix, Microsoft, PayPay y más de otras 30 grandes compañías tecnológicas leyendo detenidamente el código que sus desarrolladores habían colgado en repositorios públicos de GitHub y otras plataformas.

Birsan no estaba buscando "secretos al uso" como contraseñas o tokens. En su lugar, estaba buscando "dependencias públicas" que activarían partes del código en el repositorio público. El caso es que también encontró en el código público referencias a esas dependencias privadas, por lo que asumiendo sus nombres podía activar partes del código oculto, privado, y así ganar acceso a las redes de estas compañías.

Un hacker detecta un sencillo método para irrumpir en los sistemas de 35 grandes tecnológicas como Apple, Microsoft, Netflix o Tesla: cómo protegerse

En respuesta a los hallazgos de Birsan, GitHub publicó un post en su blog en el que detallaban los pasos a seguir para que los desarrolladores asegurasen que sus códigos no eran vulnerables a esta táctica de "confusión de dependencias", y la matriz de la plataforma, la propia Microsoft, publicó un white paper al respecto. En el mismo la firma destacaba que el hallazgo era resultado de una "brillante investigación" y abundando en que GitHub estaba ahora trasladando esos descubrimientos a sus usuarios.

"Fue una intensa discusión la que tuvimos aquí", admite Hanley. "Estamos ahora pidiendo a todo el mundo que presten atención a este tema y ayudando a los usuarios a entender cuáles son las mejores prácticas para mantener sus códigos a salvo y que se puedan adaptar a estos hallazgos".

Este artículo fue publicado originalmente en BI Prime