código abierto
Las empresas TI fueron las primeras en adoptar el código abierto, después, muchas grandes empresas siguieron su ejemplo. A fin de cuentas, la capacidad de reutilizar y modificar el código de forma independiente, así como corregir errores, estimula la rápida innovación y la reducción de costes.
Pero el código abierto también presenta algunas características negativas inherentes, debido a las responsabilidades difusas a la hora de crear y mantener el código. Endor Labs, con la ayuda de más de 20 directores de seguridad de la información y de tecnología de grandes empresas TI, ha llevado a cabo un análisis sistemático para generar esta lista con los 10 riesgos principales a los que se enfrentan.
Las vulnerabilidades conocidas
El riesgo más importante que identificaron fue la presencia de vulnerabilidades tanto en el propio proyecto de código abierto como en sus dependencias, es decir, los componentes externos de código abierto utilizados en el proyecto. Estas vulnerabilidades en las dependencias pueden causar problemas graves para docenas de paquetes de software comercial, como fue el caso de la biblioteca Apache Log4j (CVE-2021-44228).
Medidas de seguridad: Analiza periódicamente tus aplicaciones en busca de vulnerabilidades conocidas, incluidas las vulnerabilidades en las dependencias directas e indirectas y aplica las correcciones disponibles cuanto antes. Para optimizar los recursos de la empresa, puedes dar prioridad a los parches en función de la gravedad de una vulnerabilidad determinada y la probabilidad de su explotación en el software que estás utilizando.
El compromiso de paquetes legítimos
Dado que hasta el 80 % del código del proyecto de código abierto se hereda de otros proyectos en forma de las famosas dependencias, siempre existe la posibilidad de que los componentes de terceros utilizados en tu aplicación se hayan infectado con un troyano. Esto puede suceder cuando el desarrollador de estos componentes ha sufrido un hackeo o se descubre que el sistema de distribución de componentes, es decir, el administrador del paquete, contiene una vulnerabilidad que permite falsificarlo. En este caso, el código malicioso de terceros aparece repentinamente dentro de tu aplicación, que en la práctica se suele utilizar para robar información o para varias estrategias de enriquecimiento ilícito (spam, estafas de adware, minería).
Medidas de seguridad: Actualmente no existe una metodología asentada para protegerse contra esta amenaza, por lo que necesitarías una combinación de medidas: sistemas manuales y automáticos para analizar el código fuente y monitorizar los repositorios, almacenamiento local de versiones de confianza de los componentes y el uso de la inteligencia de amenazas para detectar estos ataques en sus primeras etapas, antes de que tengan tiempo de afectar a los paquetes utilizados en las aplicaciones de código abierto de la empresa.
El ataque de los “homónimos”
Los atacantes crean paquetes con nombres que se asemejan a otros legítimos o copian los de paquetes legítimos escritos en otros lenguajes de programación o publicados en otras plataformas de distribución. Esto genera el riesgo de que tus desarrolladores de código abierto integren un paquete malicioso “del mismo nombre” en lugar del original.
Medidas de seguridad: Pide a los desarrolladores que estén atentos. Además, deben adquirir la rutina de verificar el código fuente de los paquetes antes de su uso en busca de peculiaridades como fragmentos cifrados en el código, secuestro de funciones y similares. También es recomendable comprobar las firmas digitales de los paquetes (si las hay).
El código sin soporte
Los desarrolladores de componentes, paquetes y aplicaciones de código abierto pueden retirar el soporte en cualquier momento y por cualquier motivo. Esto pasa a menudo en los paquetes pequeños desarrollados por 1 o 2 personas. Si sucede, no hay nadie que actualice el paquete para que sea compatible con las nuevas tecnologías o elimine los riesgos de seguridad de la información.
Medidas de seguridad: evalúa el nivel de madurez del proyecto y las perspectivas de desarrollo/soporte antes de integrarlo en tus procesos comerciales y el propio código. Presta atención a la cantidad de desarrolladores que mantienen el proyecto y la frecuencia de los lanzamientos. Comprueba las versiones de soporte a largo plazo (LTS por sus siglas en inglés) y cuándo salieron. Sin embargo, en el caso de algunos proyectos estables, es bastante normal que los lanzamientos sean poco frecuentes y solo solucionen errores.
El software obsoleto
El uso de versiones antiguas de componentes en proyectos hace que la aplicación de los parches sea mucho más difícil. Este problema resulta especialmente grave en el caso del riesgo número uno: vulnerabilidades en los componentes. Por lo general, surge un problema con las dependencias obsoletas cuando una nueva versión de un componente difiere significativamente de las iteraciones anteriores en la sintaxis o semántica. En esta situación, una versión desactualizada puede permanecer en uso durante muchos años sin actualizaciones de seguridad.
Medidas de seguridad: Concede tiempo a los desarrolladores para trabajar con dependencias, incluida la refactorización del código para actualizar a las últimas versiones de los componentes en uso.
Las dependencias sin rastrear
Dado que casi todas las aplicaciones usan componentes de terceros, que a su vez usan otros componentes de terceros, a menudo los desarrolladores de la aplicación principal desconocen la presencia de un componente en particular en su código. En este caso, no se comprueban todos los demás riesgos de la lista. El estado de las actualizaciones, vulnerabilidades y demás simplemente se desconoce.
Medidas de seguridad: Recopila una lista de materiales de software (SBOM por sus siglas en inglés) detallada con el uso de herramientas de escaneo que pueden detectar incluso las dependencias que se usan sin un administrador de paquetes.
Riesgos regulatorios y de licencias
A pesar de ser de código abierto, cada aplicación y paquete de código abierto viene con su propia licencia de uso. Los riesgos surgen si la licencia resulta ser incompatible con el uso de la aplicación para el propósito previsto o si las licencias de algunos componentes de la aplicación son incompatibles entre sí. También puede pasar que uno o más componentes de la dependencia infrinjan las leyes aplicables o los requisitos reglamentarios impuestos en la empresa.
Medidas de seguridad: Las herramientas de escaneo de código y SBOM ya mencionadas deben usarse para realizar un seguimiento de las licencias y los requisitos de licencia aplicables a las aplicaciones y componentes de código abierto utilizados dentro de la empresa. Por tanto, tiene sentido trabajar con el departamento legal para desarrollar una lista de licencias estándar aceptables para la empresa, detallando su compatibilidad con el propósito del software utilizado. El software con licencias incompatibles o sin ningún tipo de licencia debe eliminarse.
El software inmaduro
Utilizar componentes desarrollados por un equipo que carece de madurez conlleva una serie de inconvenientes y riesgos. Los problemas asociados con el software inmaduro van desde una documentación de código insuficiente o inexacta hasta un funcionamiento inestable y propenso a errores y a la ausencia de un conjunto de pruebas para las pruebas de regresión. Además, hay más probabilidades de que el código inmaduro albergue vulnerabilidades críticas. Todo esto hace que el uso de software inmaduro resulte poco práctico y aumenta tanto los costes involucrados como los riesgos de situaciones críticas y tiempos de inactividad.
Medidas de seguridad: Antes de implementar una aplicación o componente, asegúrate de que los desarrolladores estén implementando las mejores prácticas del momento: tener documentación completa y actualizada, segmentaciones CI/CD para pruebas de regresión, así como información detallada sobre la cobertura de la prueba e incluso la cantidad de paquetes que ya usa el componente.
Los cambios sin aprobación
Los componentes utilizados por una aplicación pueden cambiar de forma completamente imperceptible para sus desarrolladores. Esta situación puede tener lugar si los componentes se descargan de un servidor sin un control estricto de versiones y/o a través de canales de comunicación no cifrados y no se verifican mediante hash y firmas digitales. En este caso, el ensamblaje de la aplicación teóricamente puede producir un resultado diferente cada vez.
Medidas de seguridad: Sé estricto con la aplicación de prácticas de desarrollo seguras. Durante el desarrollo, utiliza identificadores de recursos que indiquen claramente la versión del componente. Además, comprueba los componentes descargados mediante firmas digitales. Utiliza siempre protocolos de comunicación seguros.
Las dependencias demasiado grandes o demasiado pequeñas
Actualmente, los desarrolladores pueden integrar un componente con solo tres líneas de código. A su vez, es igualmente perjudicial cuando todo el componente consta de cuatro líneas de código (muy pequeñas) y cuando el código que intentas usar es solo una de las miles de características del componente, el resto de las cuales no se usan en la aplicación de la empresa. En este caso, los desarrolladores tienen la carga de mantener otra dependencia más por el bien de una muy deficiente funcionalidad.
Medidas de seguridad: Evita las dependencias con poca funcionalidad; desarrolla esta funcionalidad dentro de la aplicación principal.
