vulnerabilidades del software de código abierto

7 Riesgos del software de código abierto y cómo defenderse

This post was last updated on agosto 10th, 2021 at 05:59 pm

¿Qué es el software de código abierto?

Muchas empresas y productos, el 90% según algunas estimaciones, utilizan al menos un componente de código abierto, incluso si no son conscientes de ello. El software de código abierto es software cuyo código está disponible para la inspección pública, modificación y mejora. Típicamente, este software se crea a través de la colaboración de la comunidad y se mantiene y actualiza de forma voluntaria.

El software de código abierto puede ser utilizado de acuerdo a una variedad de licencias, dependiendo de lo que los creadores hayan implementado. Linux OS, Apache Web Server, WordPress y Mozilla Firefox son sólo algunos de los programas más utilizados disponibles.

Riesgos del uso de software de código abierto

Debido a la construcción de la comunidad y a su distribución en gran medida no regulada, el uso de software de código abierto conlleva una serie de riesgos, entre los que se incluyen algunos riesgos de ciberseguridad.

1. Las vulnerabilidades son de conocimiento público

Las vulnerabilidades en el software de código abierto son de conocimiento público por los propios contribuyentes, así como por organizaciones como el Open Web Application Security Project (OWASP) y la National Vulnerability Database (NVD).

Si usted es parte de la comunidad para un proyecto específico, a menudo recibe un aviso previo antes de que se haga público a grupos como OWASP y NVD, pero también lo hace cualquier otra persona que forme parte de la comunidad. Esto significa que si usted es negligente en el mantenimiento de las últimas versiones o en la actualización de componentes, se expone a riesgos, ya que las vulnerabilidades suelen ser identificadas y explotadas por los ciberdelincuentes.

2. Falta de seguridad

El software de código abierto no tiene ningún tipo de reclamo ni obligación legal en materia de seguridad y el apoyo de la comunidad le informa de cómo implementarlo de forma segura puede ser insuficiente. Los desarrolladores responsables de la creación de software a menudo no son expertos en seguridad y es posible que no sepan cómo implementar las mejores prácticas.

Aunque recursos como la lista de las 10 principales vulnerabilidades de OWASP están disponibles públicamente y dirigidos a las comunidades de código abierto, no siempre proporcionan instrucciones sobre cómo implementar características de seguridad para protegerse contra estos defectos.

A menudo el software de código abierto incluye o requiere el uso de librerías de terceros, extraídas de los gestores de paquetes sin inspección. La naturaleza de caja negra de estas bibliotecas hace que sea más difícil y lento identificar y parchear cualquier vulnerabilidad que puedan inyectar.

3. Cuestiones de propiedad intelectual

Existen más de 200 tipos de licencias que se pueden aplicar al software de código abierto, incluyendo Apache, GPL y MIT. Muchas de estas licencias son incompatibles entre sí, lo que significa que ciertos componentes no se pueden utilizar juntos, ya que hay que cumplir con todos los términos cuando se utiliza software de código abierto. Cuantos más componentes utilice, más difícil le resultará rastrear y comparar todas las estipulaciones de la licencia.

Algunas licencias incluyen cláusulas de "copyleft" que requieren que libere cualquier software creado con los componentes cubiertos como código abierto, en su totalidad. Esto hace imposible su uso en software privativo y menos atractivo para su uso con fines comerciales.

4. Falta de garantía

El software de código abierto no viene con ninguna garantía en cuanto a su seguridad, soporte o contenido. Aunque muchos proyectos son apoyados, son realizados por voluntarios y el desarrollo de los mismos puede ser abandonado sin previo aviso.

Los miembros de la comunidad normalmente evalúan el software en busca de problemas de seguridad y proporcionan soporte a través de foros abiertos, pero no están obligados a hacerlo ni son responsables de una orientación errónea.

Dado que el software de código abierto es creado por comunidades de contribuyentes a veces anónimos, es difícil verificar que el código que se está contribuyendo sea original y no provenga de una fuente de terceros con derechos de propiedad intelectual establecidos. Lo que esto significa en la práctica es que si usas software de código abierto que contiene código con derechos infringidos, puedes ser considerado responsable de la infracción.

5. Supervisión de Integraciones Relajadas

Los equipos a menudo tienen procesos de revisión insuficientes o inexistentes cuando se trata de los componentes de código abierto que se están utilizando. Múltiples versiones del mismo componente pueden ser utilizadas por diferentes equipos o los desarrolladores pueden no ser conscientes de la existencia de funcionalidades o licencias conflictivas.

Estos problemas pueden ocurrir debido a la falta de conocimiento del software o de la funcionalidad de seguridad, a la falta de comunicación entre los equipos o entre los miembros de los equipos, o a la insuficiencia o ausencia de protocolos de seguimiento y documentación.

A diferencia del software propietario de terceros, que tiene controles incorporados para evitar el uso de versiones múltiples o incompatibles, los componentes de código abierto suelen confiar en el usuario para verificar el uso correcto.

6. Insuficiencias operativas

El uso de componentes de código abierto puede crear mucho trabajo adicional para equipos que ya tienen poco tiempo y a menudo no está claro quién es el responsable de este trabajo. Debe llevar un registro de los componentes que se utilizan, de su versión, de dónde se utilizan y de cómo podrían interactuar con otros componentes en uso.

Además, es necesario comparar las licencias y supervisar las actualizaciones y los parches a medida que se ponen a disposición, incluido el impacto que pueden tener en la funcionalidad. Si los componentes utilizados contienen funcionalidades innecesarias, pueden añadir complejidad a su sistema sin ningún beneficio.

7. Prácticas deficientes de los desarrolladores

Los desarrolladores pueden aumentar los riesgos inadvertidamente si copian y pegan secciones de código de software de código abierto en lugar de integrar componentes completos. Hacerlo hace imposible rastrear ese código desde una perspectiva de licenciamiento o seguridad.

Cuando colaboran con otros miembros del equipo, los desarrolladores pueden transferir componentes a través del correo electrónico en lugar de a través de un gestor de repositorios binarios o una ubicación de red compartida. Este método puede dejar el código vulnerable a la manipulación durante la transferencia, permitiendo la inserción de fallas de seguridad o funcionalidad maliciosa.

Cómo protegerse a sí mismo y a su organización

Use las herramientas adecuadas

La implementación de los equipos de DevSec puede ayudarle a integrar la seguridad más temprano en su SDLC e integrar el software de código abierto de forma segura desde el principio. Los miembros de seguridad pueden evaluar más fácilmente los componentes que los desarrolladores desean utilizar y proporcionar orientación sobre cómo mitigar los riesgos o el desarrollo de parches.

Las herramientas de automatización pueden proporcionar un enorme valor para el seguimiento de los componentes de código abierto y su estado, así como para la evaluación de componentes. El código fuente abierto puede ser escaneado antes y durante su uso a través de las herramientas Dynamic Application Security Testing (DAST) o Static Application Security Testing (SAST).

Cree políticas integrales

Las políticas deben requerir la consideración del historial de un componente de código abierto, como la densidad de los problemas conocidos, la frecuencia de publicación de la versión y la latencia entre la identificación de problemas y el parche. Es importante saber cuán sólida es la comunidad involucrada en un proyecto y anticipar qué tipo de apoyo podría o no proporcionar.

Las políticas deben dictar qué fuentes y tipos de licencia son aceptables para su uso y deben ayudar a los desarrolladores a decidir si utilizan componentes individuales o una base de código completa.

Conclusión

Muchas empresas se benefician del uso de software de código abierto y no hay razón para que usted no se beneficie también. Sin embargo, conocer los riesgos que plantea el software de código abierto, al entrar en el proceso de desarrollo, le ayudará a evitar las trampas asociadas con el hecho de compartir código de fuentes múltiples. Teniendo en cuenta los riesgos descritos en este blog e implementando estrategias de protección, además de otras necesarias para proteger sus sistemas, usted puede ayudar a garantizar el uso seguro del software de código abierto.

Publicado en

Test out Infocyte's endpoint + Microsoft 365 detection and response platform for free. Sign-up for our community edition here and get started in minutes: