En 2018 nos sacudió la noticia de que Java ya no iba a ser gratuito (en algunos casos, como explicamos en nuestros anteriores artículos que puedes ver aquí y aquí ) 2018 pudo haber supuesto un cambio de paradigma respecto al software OpenSource donde Java siempre había sido uno de los ejemplos más fuertes pero, para ser sinceros, todo el mundo se adaptó bastante bien. Fue el primer tropezón.
Desde la selección del lenguaje hasta el proceso de despliegue, pasando por las librerías el ciclo de vida del desarrollo de software está lleno de riesgos, veamos algunos de ellos. 👀
El caso de Log4j
Después de lo del licenciamiento de Java en diciembre de 2021 apareció un ataque a Java de los denominados “zero-day” debido a una vulnerabilidad de Log4j/ Log4shell y algunas vulnerabilidades posteriores. Independientemente de los detalles del problema técnico parece que había un problema de base: Log4j es una librería desarrollada y mantenida por un grupo muy reducido de personas en su tiempo libre porque era “shareware”. Podéis hacer una revisión más profunda del ataque aquí 👈👈.
Miles de empresas usan una pequeña pieza de código que había resultó ser crítica; y la mantenían unos tipos a base de buena voluntad. Log4j es una de las librerías más usadas del mundo 🌎 (en noviembre de 2021 tenía el puesto 252 de un total de 7.1 millones, y se usa en más de 7000 otros proyectos OpenSource y librerías).
“¿Quién hace el mantenimiento? ¿A quién le importa?” 🤔 Esto pasa con muchas librerías, pero desgraciadamente el incidente de Lo4j tampoco cambió nada.
Más a tener en cuenta al usar software OpenSource 👇👇
Otro de los problemas que han aparecido es lo que se llama ProtestWare y ocurre cuando un desarrollador OpenSource borra su código o lo inutiliza. Ha ocurrido en varias ocasiones, quizá el más relevante haya sido el incidente “leftpad” o el auto-hackeo de “colors and faker”.
Las causas del ProtestWare son variadas pero generalmente tiene la raíz es el hecho de que a la mayoría de los desarrolladores de software OpenSource no se les compensa por ello ni se les reconoce. Más aún, a veces se les presiona para que cumplan con nuevas regulaciones mientras que se presupone que seguirán trabajando gratis. Y las empresas que usan su software raramente contribuyen en nada.
Más recientemente un bug en un fallo en un software de Antivirus impedía a sus usuarios que llegasen a Google.com o Youtube.com.
¿Esto es porque Malware Bytes es gratuito para los usuarios domésticos? Seguramente no, pero pone una pica en Flandes: las cosas gratuitas son buenas hasta que dejan de ser de alguna manera gratuitas por alguna razón. Por eso pagar por las cosas que merecen la pena es bueno, especialmente en el entorno corporativo.
¿Por qué pagar por el software libre? ❓❓
Porque al final te puede costar mucho, mucho más no hacerlo. Volviendo a la vulnerabilidad de log4j. ¿Habéis intentado medir lo que os ha costado el análisis de Ciberseguridad? ¿El parcheo y redespliegue de todas las aplicaciones que usaban la librería? Y ¡varias veces! Porque el bug no se resolvió con un único parche sino con varios en un largo periodo de tiempo (este es un resumen de los bugs de log4j).
Pero aún hay más 😱
¿Habéis sido capaces de localizar absolutamente todos los log4j que se ejecutan en todos vuestros sistemas? Puede que aún seáis vulnerables a log4j incluso un año después.
Los riesgos del flujo de desarrollo ❌
Cuando conocí el incidente “Leftpad” pensé “¿Qué? ¿Hay alguien que importe esto como una librería? El fragmento de código es minúsculo, yo diría que cualquier lenguaje de programación moderno debería incluirlo por defecto pero si no lo tiene seguramente lo codificaría yo mismo o lo copiaría en mi código “¡hereje!” gritan por ahí. Pues seguramente lo sea. Copiar el código va en contra del principio de atribución pero ¿no es lo que se hace a diario en Stack overflow? Además así soy yo quien asume el mantenimiento y no el creador. Pero también me protege contra ataques de ProtestWare o Poisoned Pipeline Execution u otros riesgos de seguridad de CI/CD (Integración continua y entrega continua) como el que sufrió British Airways por el uso de una modificación de una librería.
Como podéis ver cada opción tiene sus beneficios y desventajas; aun así las comprobaciones de seguridad se deben extender a todas las fases del ciclo de vida del software. A veces las grandes compañías no son capaces de ver los costes de no hacer buen software. No hablo sólo de Java, Javascript, R o Python (los menciono por la gran cantidad de librerías que tienen) sino literalmente por cada pieza de código que usen o importen.
Vigilando todas las fases del desarrollo de proyectos 🧐
Incluso la elección del lenguaje es importante. El CTO de Microsoft Azure, Mark Russinovich dice que debería dejar de usarse C y C++. No sólo porque son lenguajes no gestionados (aún muy útiles para muchos casos de uso) sino porque al programar en ellos somos más propensos a cometer errores. Microsoft está dando soporte a Rust no solo por la gestión de memoria sino porque es tan eficiente como C/C++ (se puede ver la publicación aquí) mientras que Java está a mitad de tabla.
Para ser justos, hay que reconocer que el software OpenSource es uno de los motores más potentes de la “nueva informática”. Sin Linux, Java, MySQL y muchos otros podríamos estar aun intentando evolucionar de la arquitectura de aplicaciones de dos capas.
Larga vida al OpenSource, pero cúbrete las espaldas sabiendo lo que estás haciendo 😉
Santander Global T&O es una compañía del Grupo Santander con más de 3.000 empleados y basada en Madrid, trabajamos para convertir al Santander en una plataforma abierta de servicios financieros.
Mira las posiciones que tenemos abiertas aquí para unirte a este equipazo y Be Tech! with Santander
Síguenos en LinkedIn y en Instagram.
Juan Tavira
Universia
Especialista, arquitecto y friki multidisciplinar apasionado de todas las innovaciones. Esto es fácil de decir por uno mismo, pero cuando lo dicen mis compañeros informáticos, mis amigos geeks de los juegos e incluso mi mujer, algo de verdad tendrá ;-). Me gusta construir violines como hobby. En ocasiones veo código.
