> El uso del código fuente abierto puede reducir significativamente el tiempo y los recursos abiertos, pero nadie puede garantizar que el código de código abierto no tenga errores, ni puede garantizar que adopte un proceso de gestión de código de código fuente abierto que cumpla con los requisitos de aplicaciones empresariales durante el proceso de desarrollo.

Al desarrollar aplicaciones internas y externas, las empresas usan cada vez más el código fuente abierto, lo cual es razonable. El uso de componentes preconstruidos gratuitos sin escribir su propio código puede acortar significativamente el tiempo de desarrollo de aplicaciones y aumentar la probabilidad de éxito del desarrollo de software. Al desarrollar aplicaciones, el equipo de desarrollo puede usar fácilmente más de cien bibliotecas, marcos y herramientas de código abierto, así como innumerables código de Internet.

Sin embargo, el código de código abierto tiene riesgos, incluso la base de código más ampliamente reconocida. Nadie puede garantizar que el código de código abierto no tenga errores, ni que adopte un proceso de administración de código de código abierto que cumpla con los requisitos de aplicaciones empresariales durante el proceso de desarrollo. Incluso si un proyecto de código abierto tiene una comunidad de usuarios activo, puede tener vulnerabilidades nuevas y antiguas. Por ejemplo, el marco de aplicaciones web de código abierto en Rails en Rails ha encontrado varias vulnerabilidades de seguridad este año, con un estimado de 200,000 sitios web que probablemente serán atacados por la ejecución de código remoto. Peor aún, estos errores aparecieron en 2007, lo que significa que todas las versiones de este marco han tenido tales problemas durante más de 6 años. En este artículo, introduciremos el rango de riesgos planteados por el código fuente abierto a las aplicaciones empresariales y las formas de reducir los riesgos utilizando técnicas de gestión de código de código abierto.

#### Código de código abierto y componentes vulnerables

Algunas personas creen que los riesgos planteados por el código fuente abierto para las aplicaciones empresariales son limitados, porque muchas veces el código de código abierto solo se aplica a componentes de aplicación limitados. Sin embargo, los componentes de la aplicación casi siempre tienen todos los permisos para toda la aplicación, por lo que un componente problemático siempre puede tener graves consecuencias.

Las vulnerabilidades de cualquier código pueden ser muy pequeñas o graves, y la dificultad de los ataques puede ser grande o pequeña, pero las vulnerabilidades que ocurren en marcos, bibliotecas o componentes generales obviamente tienen un mayor riesgo. El conjunto de herramientas de hackers gratuitos ahora se actualiza muy rápidamente, y agregarán estas vulnerabilidades recién descubiertas al escáner automático, de modo que las aplicaciones que usan estos códigos de problemas se buscarán rápidamente y luego se atacan. No solo los piratas informáticos avanzados pueden lanzar ataques, sino que algunos piratas informáticos junior que usan herramientas de ataque automatizadas también pueden atacar.

Es un problema grave tener estos componentes vulnerables en nuevas aplicaciones, por lo que aparece en la última lista de vulnerabilidades de aplicaciones de OWASP Top 10. En la versión anterior de la lista OWASP, pertenece a la entrada más general de "error de seguridad", pero ahora es una entrada independiente - Artículo 9: "Uso de componentes con vulnerabilidades conocidas".

Por ejemplo, OWASP señaló que dos componentes con vulnerabilidades alcanzaron 22 millones de descargas en 2011. El primero es evitar la autenticación de Apache CXF: el marco Apache CXF no puede proporcionar un token de identidad, por lo que un atacante puede tener permisos completos para ejecutar cualquier servicio web. El segundo es el lenguaje de expresión abusado en Spring, un marco Java de código abierto, que permite a los atacantes ejecutar código arbitrario para controlar todo el servidor. ¿Cuáles son las consecuencias de esto? Mientras las aplicaciones empresariales usen estos marcos problemáticos, pueden convertirse en juego en manos de los atacantes.

### Implementar seguridad de software a través de la administración de código fuente abierto

Los beneficios del uso del código fuente abierto ciertamente superarán el tiempo y los recursos necesarios para desarrollar aplicaciones desde cero, pero por otro lado, las empresas aún tienen que usar un proceso para garantizar que todo el código de terceros se actualice. La mayoría de los equipos de desarrollo ni siquiera saben de dónde proviene algunos de este código, y mucho menos actualizaciones.

Sin embargo, no todos los proyectos de código abierto utilizan un mecanismo de numeración de versión comprensible, por lo que los informes de vulnerabilidad no siempre indican exactamente las versiones de componentes vulnerables. Afortunadamente, los sitios web como CVE y NVD proporcionan servicios que facilitan la búsqueda y consulta de esta información.

Para mejorar la gestión del código de código abierto, el equipo de desarrollo primero debe crear y mantener una última lista de uso de código de terceros, incluidos todos los códigos de dependencia y fuentes. Asigne una persona a cargo de cada fuente para rastrear listas de correo, noticias y actualizaciones. Esto no debería ser solo una actividad pasiva; Porque no todas las nuevas vulnerabilidades se informan a un centro de información centralizado, por lo que deben monitorear las listas de correo de seguridad pública. Algunos equipos pueden encontrar que tienen que reducir la cantidad de fuentes de código que usan para mejorar la eficiencia de gestión; Y, definitivamente, desarrolle una estrategia para administrar el uso de código, como casos comerciales, evaluaciones de riesgos y autorizaciones aceptables.

Si una aplicación usa el código en cuestión, primero verifique si usa la parte del código que contiene la vulnerabilidad y luego evalúa si tiene el riesgo de manejarlo. Es importante tener en cuenta que muchos proyectos de código abierto no liberan parches; En cambio, generalmente solucionan el problema al lanzar nuevas versiones. Hay un plan de respuesta de emergencia para manejar algunas versiones importantes, ya que se deben analizar muchas aplicaciones conectadas a Internet y pueden requerir una medida de respuesta rápida para evitar que los atacantes rompan con éxito la vulnerabilidad.

Los desarrolladores empresariales que utilizan bibliotecas de código abierto deben ser conscientes de los riesgos del código de código abierto. Incluso si estos códigos pueden reducir significativamente el tiempo de desarrollo de software, usarlos puede aumentar innecesariamente las vulnerabilidades en las aplicaciones empresariales, aumentando así el nivel de riesgo de la organización, requerir más tiempo para lidiar con los riesgos. Para ser conscientes de estos problemas, las empresas pueden utilizar de manera segura las bibliotecas y marcos de código abierto sin poner aplicaciones y toda la organización con un riesgo innecesario.