7 riesgos que plantea el software de código abierto y cómo protegerse
¿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, aunque no sean conscientes de ello. El software de código abierto es aquel cuyo código está disponible para que el público lo examine, modifique y mejore. Por lo general, este software se crea mediante la colaboración de la comunidad y se mantiene y actualiza de forma voluntaria.
El software de código abierto se puede utilizar bajo diversas licencias, dependiendo de lo que hayan implementado sus creadores. El sistema operativo Linux, el servidor web Apache, WordPress y Mozilla Firefox son solo algunos de los programas más utilizados que hay disponibles.
Riesgos del uso de software de código abierto
Debido a su desarrollo comunitario y a su distribución en gran medida no regulada, el uso de software de código abierto conlleva diversos riesgos, incluidos algunos relacionados con la ciberseguridad.
1. Las vulnerabilidades son de dominio público
Las vulnerabilidades en el software de código abierto son dadas a conocer por los propios colaboradores, así como por organizaciones como el Open Web Application Security Project (OWASP) y la Base de Datos Nacional de Vulnerabilidades (NVD).
Si formas parte de la comunidad de un proyecto específico, a menudo recibes un aviso previo antes de que se haga público a grupos como OWASP y NVD, pero lo mismo ocurre con cualquier otra persona que forme parte de la comunidad. Esto significa que, si no te mantienes al día con las últimas versiones o con la actualización de los componentes, te estás exponiendo a riesgos, ya que los ciberdelincuentes suelen identificar y explotar las vulnerabilidades.
2. Falta de seguridad
El software de código abierto no conlleva ninguna garantía ni obligación legal en materia de seguridad, y es posible que falte información sobre cómo implementarlo de manera segura. Los desarrolladores responsables de crear el software a menudo no son expertos en seguridad y es posible que no comprendan 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 están dirigidos a las comunidades de código abierto, no siempre ofrecen instrucciones sobre cómo implementar medidas de seguridad para protegerse contra estas fallas.
A menudo, el software de código abierto incluye o requiere el uso de bibliotecas de terceros, que se obtienen de los administradores de paquetes sin ser inspeccionadas. La naturaleza de caja negra de estas bibliotecas hace que sea más difícil y lento identificar y corregir cualquier vulnerabilidad que puedan introducir.
3. Cuestiones de propiedad intelectual
Existen más de 200 tipos de licencias que se pueden aplicar al software de código abierto, entre ellas 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 es necesario cumplir con todos los términos al usar software de código abierto. Cuantos más componentes se utilicen, más difícil resulta dar seguimiento y comparar todas las estipulaciones de las licencias.
Algunas licencias incluyen cláusulas de «copyleft» que exigen que cualquier software creado con los componentes cubiertos se publique como código abierto, en su totalidad. Esto hace que sea imposible utilizarlo en software propietario y lo hace menos atractivo para su uso con fines comerciales.
4. Falta de garantía
El software de código abierto no ofrece ninguna garantía en cuanto a su seguridad, soporte técnico o contenido. Aunque muchos proyectos cuentan con soporte técnico, este es proporcionado por voluntarios y su desarrollo puede interrumpirse sin previo aviso.
Los miembros de la comunidad suelen evaluar el software en busca de problemas de seguridad y brindar apoyo a través de foros abiertos, pero no están obligados a hacerlo ni son responsables por una orientación errónea.
Dado que el software de código abierto es creado por comunidades de colaboradores, a veces anónimos, es difícil verificar que el código aportado sea original y no provenga de una fuente de terceros con derechos de propiedad intelectual establecidos. En la práctica, esto significa que si utiliza software de código abierto que contenga código con derechos infringidos, usted puede ser considerado responsable de la infracción.
5. Supervisión relajada de las integraciones
Los equipos suelen tener procesos de revisión insuficientes o inexistentes en lo que respecta a los componentes de código abierto que se utilizan. Es posible que diferentes equipos utilicen múltiples versiones del mismo componente o que los desarrolladores no sean conscientes de conflictos de funcionalidad o de licencias.
Estos problemas pueden surgir debido a la falta de conocimiento sobre el software o las funciones de seguridad, la falta de comunicación entre equipos o entre los miembros de un equipo, o la insuficiencia o ausencia de protocolos de seguimiento y documentación.
A diferencia del software propietario de terceros, que cuenta con controles integrados para evitar el uso de versiones múltiples o incompatibles, los componentes de código abierto suelen depender del usuario para verificar su uso adecuado.
6. Deficiencias operativas
El uso de componentes de código abierto puede generar mucho trabajo adicional para equipos que ya cuentan con poco tiempo, y a menudo no queda claro quién es responsable de este trabajo. Debe llevar un registro de qué componentes se utilizan, qué versión tienen, dónde se utilizan y cómo podrían interactuar con otros componentes en uso.
Además de esto, es necesario comparar las licencias y supervisar las actualizaciones y los parches a medida que están disponibles, incluyendo el impacto que puedan tener en la funcionalidad. Si los componentes utilizados contienen funcionalidades innecesarias, pueden añadir complejidad a su sistema sin aportar ningún beneficio.
7. Malas prácticas de desarrollo
Los desarrolladores pueden aumentar los riesgos sin darse cuenta si copian y pegan secciones de código de software de código abierto en lugar de integrar componentes completos. Al hacerlo, se vuelve imposible dar seguimiento a ese código desde el punto de vista de las licencias o la seguridad.
Al colaborar con otros miembros del equipo, los desarrolladores pueden transferir componentes por correo electrónico en lugar de utilizar 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, lo que permite la inserción de fallos de seguridad o funcionalidades maliciosas.
Cómo protegerse a sí mismo y a su organización
Utilice las herramientas adecuadas
La implementación de equipos DevSec puede ayudarte a integrar la seguridad en una etapa más temprana de tu ciclo de vida de desarrollo de software (SDLC) y a incorporar software de código abierto de manera segura desde el inicio. Los miembros del equipo de seguridad pueden evaluar con mayor facilidad los componentes que los desarrolladores desean utilizar y brindar orientación sobre cómo mitigar los riesgos o desarrollar parches.
Las herramientas de automatización pueden aportar un gran valor para el seguimiento de los componentes de código abierto y su estado, así como para la evaluación de los componentes. El código abierto se puede analizar antes y durante su uso mediante herramientas de pruebas dinámicas de seguridad de aplicaciones (DAST) o pruebas estáticas de seguridad de aplicaciones (SAST).
Crear políticas integrales
Las políticas deben exigir que se tenga en cuenta el historial de un componente de código abierto, como la densidad de problemas conocidos, la frecuencia de lanzamiento de versiones y el tiempo que transcurre entre la identificación del problema y el parche. Es importante conocer la solidez de la comunidad involucrada en un proyecto y anticipar qué tipo de soporte podría o no proporcionar.
Las políticas deben establecer qué fuentes y tipos de licencia son aceptables para su uso y deben ayudar a los desarrolladores a decidir si utilizar 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 adentrarse en el proceso de desarrollo— le ayudará a evitar los escollos asociados con el uso compartido de código de origen colectivo. Al tomar en cuenta los riesgos descritos en este blog e implementar estrategias de protección, además de otras medidas necesarias para proteger sus sistemas, puede ayudar a garantizar el uso seguro del software de código abierto.
