El software de código abierto  (OSS)  es fundamental para el desarrollo moderno, pero también puede ser un punto débil en la cadena de suministro de software. Recientemente, han surgido preocupaciones sobre su seguridad, especialmente tras el incidente de XZ Utils, donde se descubrió una puerta trasera en un software OSS ampliamente utilizado. Aunque no tuvo el mismo impacto que Log4j, donde se destacó una fragilidad del ecosistema digital actual y la necesidad de mejorar la seguridad en el uso de OSS. 

Tradicionalmente, la gestión de vulnerabilidades se ha enfocado en las vulnerabilidades conocidas, que suelen publicarse en listas como las de vulnerabilidades y exposiciones comunes. Cada vez se reconoce más la necesidad de prever riesgos potenciales que puedan estar asociados con ciertas bibliotecas, componentes y proyectos de OSS. 

Estos son 6 de los principales riesgos del código abierto 

1 – Paquetes legítimos comprometidos 

Los ciberdelincuentes reconocen la importancia de comprometer un paquete legítimo para afectar a los usuarios, tanto a nivel organizacional como individual. Utilizan diversas tácticas para lograr este tipo de ataque, como secuestrar cuentas de los responsables del proyecto o aprovechar vulnerabilidades en los repositorios de paquetes. Para reducir este riesgo, se recomienda utilizar recursos y guías emergentes, como el Marco de Consumo Seguro de la Cadena de Suministro (S2C2F) de Microsoft, ahora donado a OpenSSF, junto con otras soluciones similares disponibles en la industria. 

2 – Ataques de confusión de nombres  

Esta modalidad de ataque se basa en crear componentes maliciosos que tienen nombres similares a paquetes o componentes legítimos de OSS, con la intención de que sean descargados y utilizados por error por posibles víctimas. Cuando estos paquetes comprometidos se integran en los sistemas de una organización, pueden comprometer la confidencialidad, integridad y disponibilidad (CIA) de sus sistemas y datos. Para prevenir estos ataques, es crucial asegurarse de que los paquetes o componentes de OSS que los desarrolladores intentan descargar sean auténticos. En este contexto, es esencial educar a los desarrolladores sobre la posibilidad de enfrentarse a ataques de confusión de nombres. 

3 – Software sin mantenimiento 

Una de las desventajas del software de código abierto (OSS), en comparación con el software propietario, es que no hay un “proveedor” que garantice su mantenimiento, actualización o soporte continuo. Un factor que agrava la falta de mantenimiento del OSS es que casi el 25% de los proyectos tienen solo un desarrollador principal y el 94% son mantenidos por 10 o menos desarrolladores. Dado que entre el 60% y el 80% de las bases de código modernas están compuestas de OSS, es fácil entender que una parte significativa del ecosistema digital, incluidos los sistemas más críticos, opera con software que recibe un soporte mínimo, lo que representa un riesgo sistémico significativo. Para mitigar este riesgo, el informe recomienda evaluar la vitalidad y salud del proyecto, considerando factores como el número de mantenedores y colaboradores, la frecuencia de las actualizaciones y el tiempo medio para remediar (MTTR) las vulnerabilidades.

4 – Dependencias no rastreadas 

Los desarrolladores y las organizaciones a menudo no están al tanto del uso que hacen de ciertas dependencias o componentes específicos. Esto puede suceder porque no emplean herramientas como el análisis de composición de software (SCA) para entender cómo consumen OSS, o porque no adoptan tecnologías emergentes como las listas de materiales de software (SBOM), que ofrecen una visibilidad clara de los componentes utilizados o distribuidos por la organización. A pesar de que el inventario de activos es un control fundamental en SANS/CIS desde hace mucho tiempo. Las SBOM buscan solucionar este problema al permitir que las organizaciones gestionen su inventario de componentes de manera más eficaz. 

5 – Riesgo de licencias y cumplimiento normativo  

Este riesgo surge cuando los componentes o proyectos carecen de licencias o tienen licencias que pueden impedir su uso de la manera que los consumidores planean. Esto podría impactar negativamente en los objetivos comerciales de la organización, incluidas las fusiones y adquisiciones, a medida que aumentan el uso de componentes OSS en sus productos y servicios. Para mitigar estos riesgos, las organizaciones deben identificar las licencias aplicables a los componentes que utilizan y asegurarse de que su uso esté alineado con dichas licencias. 

6 – Cambios no aprobados 

OWASP advierte sobre situaciones en las que los componentes pueden cambiar sin que los desarrolladores lo noten, revisen o aprueben. Esto puede ocurrir cuando los enlaces de descarga cambian, apuntan a recursos no versionados, o cuando se realizan transferencias de datos inseguros que han sido manipuladas, subrayando la importancia de un tránsito seguro. Para mitigar estos riesgos, se recomienda utilizar identificadores de recursos que aseguren la seguridad y la referencia al mismo artefacto inmutable. También es aconsejable verificar las firmas y resúmenes de los componentes antes de su instalación y uso.  

En resumen, el OSS es un componente vital del desarrollo de software moderno, pero su uso requiere una gestión cuidadosa para evitar riesgos significativos en la seguridad de la cadena de suministro de software. 

¿Quieres ser un experto en código abierto y evitar vulnerabilidades en desarrollo software? 

Holberton by Coderise se centra en enseñar habilidades prácticas y técnicas avanzadas en desarrollo de software, incluyendo la importancia de la seguridad en el desarrollo de software. Temas como la gestión de dependencias, la seguridad en la cadena de suministro de software y el manejo adecuado de licencias, son fundamentales. Holberton le brinda a sus estudiantes habilidades y conocimientos en estos aspectos para garantizar que los desarrolladores no solo sean capaces de crear software, sino también de hacerlo de manera segura y conforme a las normativas, minimizando riesgos.  

Holberton Coderise es una academia de software nacida en Silicon Valley, disruptiva e innovadora cuyo modelo ha sido destacado en publicación del Banco Interamericano de Desarrollo. En la actualidad opera en más de 20 países y en más de 29 ciudades a nivel mundial distribuidas en todos los continentes y entrena miles de participantes anualmente.

Imágenes:

En julio ocurrió algo muy extraño.

El código PyPI de Atomicwrites, una biblioteca de Python bastante popular, desapareció de repente.

No se trató de un ataque de hackers. No fue un error del repositorio de PyPI. Las máquinas no se han revelado y llevado con ellas el código que hemos escrito.

Markus Unterwaditzer, el mismo desarrollador de Atomicwrites, decidió borrar el código del repositorio. ¿La razón? Él quería protestar ante la política más reciente de PyPI que obligaba que ciertas personas de proyectos críticos activaran la autenticación a dos pasos.

“PyPI me acaba de decir que tenía que habilitar 2FA (autenticación a dos pasos) para seguir cargando este paquete. Porque creí que este era un movimiento molesto y abusivo para garantizar el cumplimiento de SOC2 para un puñado de empresas (a expensas de mi tiempo libre), eliminé el paquete y publiqué una nueva versión, solo para ver si la advertencia desaparece. lo hizo, así que eso es genial”, aseguró el autor.

Sí. Estamos en la época en la que sabotear tu propio código es una forma de protestar a través de Protestware.

¿Qué es el Protestware?

Protesware es el nombre de una tendencia que parece estar en incremento y consiste en utilizar el código como una manera de enviar un mensaje de protesta.

Y la razón por la que está causando tanto eco hoy, está en que el mayo vehículo para el protestaware está en el código abierto. Lo que resulta en una paradoja muy interesante pues durante mucho tiempo la libertad que ofrecen estas herramientas se ha convertido en el soporte de muchos desarrolladores y compañías: “no tienes que escribir tu propio código, solo utiliza el que otros han hecho”, dicen a menudo. El problema está en que los creadores de este código tienen también la libertad de cambiarlo. Y para algunos esta práctica se ha convertido en una manera de levantar su voz frente a temas sociales, compañías o incluso cambios en las plataformas que albergan sus creaciones.

El caso al inicio de este artículo no fue el único. En enero de 2022 de este año los creadores de los proyectos NPM ‘Faker’ y Broker’ modificaron su código para que un mensaje apareciera en las pantallas de sus usuarios, en protesta a las grandes corporaciones. La razón para los creadores estaba en que muchas de las empresas que estaban en la lista de las 500 compañías de Fortune usaban su software de código abierto, pero apoyaban financieramente sus proyectos o patrocinaban el mantenimiento.

En marzo de 2022 cuando el conflicto entre Rusia y Ucrania escalaba, los creadores del proyecto Node-ipc (con más de un millón de descargas) comenzaron a borrar los archivos de desarrolladores de origen ruso y bielorruso y corromper las versiones de su software para que afectaran a creadores, urgiendo a los usuarios en Rusia a levantar su voz contra la guerra. Este fue solo uno de los casos más conocidos de protestware en relación a este conflicto, pero sin duda no el último.

Imágenes: Pexels

Una de las primeras cosas que aprendes al momento de desarrollar código, es que es más fácil trabajar sobre las bases que otros han dejado. Los recursos están a la mano y plataformas como Github demuestran que la idea del desarrollador aislado es otra de esas exageraciones de Hollywood tan obsoletas como la del hacker con pinta de punkero. Una muestra de esto está en la manera en la que hoy cada vez más empresas y desarrolladores están mostrando su apoyo al código abierto (open source), buscando que sea la norma en la mayoría de proyectos.

La afirmación viene de los resultados del State of Open Source Report, un informe realizado por OpenLogic con el objetivo de medir el impacto y uso de código abierto entre los desarrolladores. Para este año se entrevistaron a más de 2660 profesionales, así como organizaciones que hacen uso de herramientas de código abierto.

Te puede inetesar: Microsoft admite haberse equivocado con el código abierto

El reporte entrega algunos datos más interesantes. Por ejemplo, el tipo de herramienta de código abierto más usada por las organizaciones son programas y frameworks con un 39.25%, seguido de bases de datos y tecnología de admistración de datos (36.45%). Estos dos primeros lugares son poca sorpresa paras las personas que han trabajado en empresas de tecnología. Lo interesante está en las posiciones por debajo, como por el ejemplo el uso de sistemas operativos (34.01%), herramientas de seguridad (23.67%) o incluso Analytics.

Por supuesto esto no significa que los usuarios de estas herramientas no tengan ciertas dudas o precauciones al momento de usarlas. Por ejemplo, un 29.54% aseguró que les preocupaba no contar con las habilidades para poder probar, usar, integrar o brindar soporte a estas herramientas. Un 26.55% expresó preocupación sobre las licencias y restricciones de algunas herramientas, mientras que un 30.73% aseguró que este tipo de herramientas no escalaban tan bien como software comercial (20.73%). Pero quizás lo más interesante esté en que un 27.51% expresó no tener ningún problema o reserva con utilizar código abierto.

Imágenes: Pixabay

Enter.co/dev  es una colaboración con Coderise.org y Holberton School Colombia para promover la comunidad de programación en Colombia.

Ahora Github permitirá que los desarrolladores creen ‘categorías’ de acceso a su código, de manera que las personas que hagan donaciones a su repositorio puedan acceder a espacios privados, que obviamente ofrecerán ventajas de acuerdo con la categoría a patrocinar.

“Los desarrolladores y organizaciones con Patrocinadores de GitHub habilitados ahora podrán adjuntar un repositorio privado a cada uno de sus niveles de patrocinio. Esto otorgará a los respectivos financiadores acceso al repositorio. Estas invitaciones son administradas automáticamente por GitHub, por lo que no queda nada por administrar después de configurarlo. Esto convierte algo que muchos de ustedes estaban haciendo manualmente en una parte compatible de Patrocinadores de GitHub. ¡Estamos emocionados de ver cómo lo usarás!”, anunció en su blog la plataforma.

Te puede interesar: GitHub 2021: un buen READMes mejora en 50% la productividad

Aunque algunos pueden pensar que incluir código detrás de ‘paywalls’ puede ser una manera de ocultar material útil información, lo cierto es que Github simplemente está tomando prestadas lecciones de sitios como Patreon. Estas plataformas se han encargado de crear un modelo que permite financiar a proyectos independientes y nuevas profesiones de la Internet (de hecho, es la manera en la que muchos de los creadores de contenido son capaces de generar ingresos adiciones). La creación de categorías hace que las personas estén dispuestas a pagar un poco más, por el acceso a ciertos beneficios (que la mayoría de las veces superan el costo extra de la suscripción).

Desde hace algunos años Github permite a los creadores el agregar enlaces de plataformas externas (como la antes mencionada Patreon). Luego la compañía agregó los ‘GitHub Sponsor’, que permiten realizar donaciones directamente a través de la plataforma. La función más reciente parece ser solo el siguiente paso natural para hacer del servicio el lugar ideal para que los desarrolladores no solo creen una comunidad, sino que puedan monetizar al mismo tiempo.

Imágenes: Pixabay

El resumen de Github de 2021 deja un mensaje claro: este es uno de los mejores momentos para desarrollar software. El repositorio de código más grande de la web publicó el 2021 State of the Octoverse Report, que es un resumen de las tendencias en desarrollo de código encontradas a lo largo del año.

De acuerdo con Github, las metas de desarrollo de software están siendo alcanzadas hoy con mayor velocidad que nunca. La plataforma asegura que las ventanas de tiempo de estos proyectos están siendo reducidas en un 33%. Esto ha sido el resultado a la combinación de frameworks más eficientes, así como en un 87% de mejora en la velocidad al reutilizar código y toolchains.

¿Cuáles son los lenguajes de los que más dependen los desarrolladores? De acuerdo con el informe, la mayoría de ellos se siguen apoyando bastante en Python y Java, así como en TypeScript.

Te puede interesar Git y Github: ¿Cuáles son sus diferencias?

El informe también entrega algunos datos por fuera de aquellos dentro de la plataforma. Por ejemplo, asegura que tan solo un 11% de los de los desarrollares esperan que sus trabajos les soliciten regresar a una ubicación física peramente. Esto es mucho menor al 41% que estaba trabajando de esta manera antes de la pandemia.

Github asegura que hay dos factores importantes permitiendo esta transición. El primero es la documentación. De acuerdo con este informe, un buen READMes (es decir, el archivo que contiene información de los otros archivos en un directorio). Así como buenas prácticas de manejo de repositorios y guías que pueden incrementar hasta en un 50% la productividad. El segundo factor es la automatización, que de acuerdo con el reporte ha generado mejoras de hasta 43% en la productividad.

Otro punto positivo está en un aumento de las prioridades al momento de alimentar nuevo talento dev. Por ejemplo, más compañías están buscando dar a sus desarrolladores mentorias, así como el poder crear mejores ambientes. De acuerdo con los equipos contactados dentro de Github, este tipo de espacios aumenta en un 46% la productividad de los desarrolladores al estar apoyados con mentores y capacitaciones.

Imágenes: Pexels

Enter.co/dev  es una colaboración con Coderise.org y Holberton School Colombia para promover la comunidad de programación en Colombia.

Las similitudes y diferencias

Git y GitHub sirven para proveer el control de un código, unificarlo e inclusive compartirlo, pero estas son todas las similaridades de las dos plataformas, según señala el portal Simple Learn. De hecho, señala que, si buscáramos una analogía, Git sería un computador, mientras que Github representaría una red de computadores que están llevando a cabo una misma tarea, pero con diferentes métodos.

¿Qué es Git?

Git es un sistema de control de versiones distribuido (DVCS) de software de código abierto y gratuito diseñado para administrar todo el historial del código fuente. Este les permite a los desarrolladores mantener un historial de las confirmaciones, revertir cambios y compartir códigos con otras personas. Para poder usarlo se debe instalar en el computador. Esto quiere decir que las personas que lo usan no necesitan de Internet para usarlo o acceder a su repositorio local.

Es actualmente unas de las herramientas más conocidas y usado por empresas como Amazon, Microsoft, Facebook, por solo nombrar algunas.

¿Qué es Github?

Github es un repositorio de Git, ofrece control de versiones y administración de códigos entre otras funcionalidades. Por ejemplo, la creación de proyectos colaborativos y seguimiento de fallas o errores. Al ser una red, no está guardado en nuestro computador, sino en la nube. Lo que quiere decir que necesita de Internet y para usarlo o acceder a su biblioteca necesitamos una conexión.

Existen versiones de escritorio, pero esto no significa que este instalado en nuestro computador, en su lugar es una herramienta que ayuda a sincronizar nuestro computador con el servidor.

Los desarrolladoras pueden usarlo como backups para crear repositorios a los que acceden después y para compartirlo con otros. Además, es importante resaltar que Git puede ser usado sin Github, pero no en viceversa. Además, las dos son herramientas gratuitas, una de las principales características de los software open-source, pero no le pertenecen a la misma compañía. Git es de Linux y fue lanzado en 2015; mientras que Github es de Microsoft.

Actualmente tienen varios competidores; por ejemplo, Gitlab. Pero esta no tiene un repositorio tan extenso como Github, resalta el portal Dev Mountain

Enter.co/dev  es una colaboración con Coderise.org y Holberton School Colombia para promover la comunidad de programación en Colombia.

Imagen: Stories en Freepik.