Hay un código de código abierto dentro de casi todos los proyectos de desarrollo de software que se te ocurran. A los desarrolladores les encanta. Pero debe comprender los riesgos ocultos y cómo minimizarlos, o podría dejar su aplicación abierta a vulnerabilidades de seguridad desconocidas.
Codificación antes del código abierto
Había una vez que los desarrolladores de software escribieron todo desde cero. Luego comenzaron a aparecer bibliotecas de códigos, kits de herramientas y otros complementos. Podría obtener una ventaja mediante el uso de un conjunto de herramientas para proporcionar alguna funcionalidad, como un módulo de informes o un widget de interfaz. Puede incluirlos en su proyecto como componentes completamente formados listos para usar y usarlos de inmediato. La alternativa era perder tiempo, dinero y esfuerzo de desarrollo reinventando la rueda.
Por supuesto, con el tiempo crearía su propia biblioteca de rutinas y módulos que habían sido escritos internamente. Entonces, cuando estaba desarrollando una nueva rutina de código o elemento de interfaz, tenía tres opciones. Escríbalo usted mismo, reutilice algún código interno previamente escrito o cómprelo en una biblioteca o kit de herramientas.
El auge del código abierto
La llegada del código fuente abierto cambió todo eso. El software de código abierto hace que el código fuente de un proyecto esté disponible gratuitamente para que otros lo usen, dentro de los límites de una licencia generalmente benigna. Tanto el crecimiento como la aceptación del código abierto han sido asombrosos. La palabra proliferación no parece cubrirlo. Ha habido un aumento fenomenal en el software de código abierto, y no solo en términos de la asombrosa cantidad de proyectos y productos de código abierto que existen, sino también en el uso del código abierto dentro de los productos comerciales.
El software de código abierto alcanzó una masa crítica hace unos años, y se ha disparado desde una posición de nicho al margen hasta convertirse en un recurso de desarrollo general totalmente aceptado. Debido a que fue impulsada y desarrollada por una comunidad y no por una empresa comercial tradicional, también se consideró una especie de aficionado.
Ahora parece que el código abierto ha crecido y madurado. Y tiene. Pero el mayor cambio ha sido una apreciación más amplia del código abierto, la comprensión de los beneficios que aporta y el reconocimiento de que incluir el código abierto en su producto no es nada de lo que avergonzarse.
Las estimaciones sugieren que los proyectos de software no triviales están escribiendo alrededor del 20 por ciento del código original como máximo. El otro 80 por ciento es de código abierto. El principal sitio de alojamiento de repositorios de código abierto, GitHub, llegó a más de 100 millones de repositorios en 2018. Y hay muchas otras plataformas Git alojadas, como GitLab y BitBucket.
El código abierto es un fenómeno de desarrollo de software. Pero no todo son rosas en el jardín de desarrollo. Hay problemas que debe tener en cuenta y gestionar.
Los problemas de seguridad
El uso de componentes de código abierto en grandes proyectos de software reduce los costos de desarrollo, acorta el tiempo de desarrollo de extremo a extremo y, como se ha argumentado, promueve la innovación. Debido a que libera a su personal de desarrollo de lo mundano, les permite concentrarse en los aspectos únicos y atractivos para el mercado de su producto.
Hay algunos productos de código abierto que tienen una entidad comercial detrás de ellos. La organización lanza su producto bajo un esquema de doble licencia. Una versión comercial tendrá un canal de soporte oficial y profesional, y puede contener otros beneficios, como extras patentados que se incluyen con el producto. También lanzan una versión respaldada por la comunidad que se beneficiará de los esfuerzos de codificación del equipo comercial, así como de las contribuciones de su propia comunidad. Las contribuciones significativas de la comunidad también regresarán a la versión comercial.
Sin embargo, la mayoría de los proyectos de código abierto están completamente impulsados por la comunidad. Pueden tener el respaldo de entidades comerciales, pero ese respaldo son donaciones y patrocinios, no contribuciones de código.
Independientemente de su procedencia, los componentes de código abierto que se eligen para ser incluidos en nuevos proyectos de desarrollo tienden a ser proyectos bien establecidos y de buena reputación por derecho propio. Se han ganado un alto grado de confianza. Pero ese no es siempre el caso. A veces, la funcionalidad que necesita está disponible, pero está contenida en un proyecto nuevo y algo no probado. Pero tienes el código fuente, ¿verdad? Puedes hacer una revisión del código.
Desde el punto de vista de la seguridad, el código abierto no es ni más ni menos seguro que el código patentado de cosecha propia. Después de todo, todo es código escrito por humanos. Los defensores del código abierto apuntan a la ley de Eric S. Raymond, que nombró en honor a Linus Torvalds, que establece que “con suficientes ojos, todos los errores son superficiales.” Con suficientes personas revisando el código y realizando pruebas beta, los problemas deben identificarse, caracterizarse y corregirse rápidamente.
Eso es cierto hasta donde llega. Pero los problemas de seguridad no son necesariamente errores. Una vulnerabilidad puede ser una circunstancia que surge como efecto secundario de una lógica compleja en un proyecto de muchos módulos de código fuente que suman millones de líneas de código. El producto hace lo que se supone que debe hacer, por lo que se ve que funciona según lo previsto. Y así pasa la revisión del código, la verificación del producto, las pruebas de campo y obtiene un certificado de buena salud.
Aparte de la suerte ciega y la casualidad, ese ciclo de revisión, prueba, prueba y lanzamiento no descubrirá vulnerabilidades de seguridad.
Por qué el código abierto es atractivo para los piratas informáticos
Además, hay aspectos del código abierto que son positivamente atractivos para los piratas informáticos y los actores de amenazas. También pueden ver el código fuente. Pueden buscar vulnerabilidades con una mentalidad diferente a la del colaborador promedio de la comunidad que, aunque puede ser un desarrollador competente, es poco probable que tenga antecedentes reales de seguridad.
Por supuesto, los contribuyentes al código abierto vienen en todos los sabores con diversos antecedentes. Sin duda, algunos de ellos tendrán experiencia en seguridad en el mundo real, pero serán la minoría. Los actores de amenazas son otra bestia por completo. Y no se limitan a encontrar vulnerabilidades, también pueden inyectarlas.
Ha habido muchos casos en los que un actor de amenazas introdujo una vulnerabilidad a través de un parche que creó y envió a un proyecto. Se abrió paso a través de la revisión del código, al código base y a la próxima versión del producto.
Quizás el mejor ejemplo de esto fue un componente de JavaScript llamado event-stream. Este proyecto de código abierto fue mantenido por un solo desarrollador. La carga de la administración del proyecto lo superó. Lo persuadieron para que se lo entregara a un nuevo mantenedor.
El nuevo mantenedor era un actor de amenazas. Se hicieron cargo del proyecto, lo ejecutaron normalmente durante un período breve y luego le agregaron un código malicioso. Cada copia de cualquier otro programa que usaba ese componente de software estaba secuestrando silenciosamente ciertos tipos de billetera Bitcoin para el actor de amenazas.
Qué puede hacer para reducir el riesgo
Al igual que con muchos aspectos de la seguridad, este riesgo se gestiona mediante la aplicación de controles. Eso requiere gobernanza, en otras palabras, políticas y procedimientos. Afortunadamente, existe un software que puede ayudar.
Crear un registro de código abierto
Necesita cuantificar el código abierto que está utilizando. Cree un registro que enumere los componentes de código abierto que utiliza en sus proyectos. Enumere cada componente de código abierto, la versión o versiones que ha usado, los proyectos en los que los ha usado, cuál es la última versión y dónde se puede descargar. En la documentación de diseño de cada uno de sus proyectos, debe enumerar los componentes de código abierto que están en uso.
El diablo está en los detalles. No olvide las dependencias y la naturaleza jerárquica de gran parte del código abierto. Los proyectos de código abierto a menudo usan otros proyectos dentro de sí mismos, anidados como muñecas rusas, o requieren que se instalen otros componentes de código abierto en la máquina de destino para que puedan usarlos.
Profundice en estas dependencias y anótelas en su registro de código abierto.
Ejecutar auditorías automáticas
Las vulnerabilidades en los paquetes de código abierto son un problema importante para NPM, el administrador de paquetes de JavaScript. Para abordar esto, crearon una herramienta de auditoría automática que buscará paquetes obsoletos con actualizaciones de seguridad.
Esto, por supuesto, tiene sus limitaciones, y es importante ser consciente y no confiar completamente en las herramientas automáticas. Solo detectará paquetes con vulnerabilidades y actualizaciones conocidas. Si el paquete tiene una vulnerabilidad, pero no se ha actualizado para solucionarlo, la auditoría de NPM no le dirá nada.
Crear un mapa de vulnerabilidad
Su registro de fuente abierta le brinda una imagen clara de la fuente abierta que utiliza. El siguiente paso es mapear vulnerabilidades conocidas en ese registro. A veces, estos se pueden descubrir visitando la página de inicio del proyecto y mirando la lista de problemas conocidos.
La base de datos nacional de vulnerabilidades (NVD) le brindará una imagen mucho más granular. Puede usar su página de búsqueda para buscar productos por nombre y averiguar qué vulnerabilidades y exposiciones comunes afectan a ese componente de software. El NVD es un gran recurso, incluso si su formato requiere un poco de descifrado hasta que te acostumbras.
Actualice su registro y mapa de vulnerabilidades
Por supuesto, esto es algo que debes tener al tanto. Se descubren nuevas vulnerabilidades todo el tiempo, por lo que es probable que el estado de seguridad de su producto en el momento del lanzamiento se deteriore lentamente con el tiempo.
Reconociendo esta nueva necesidad, existen aplicaciones comerciales (Black Duck, WhiteSource) que ayudarán con esto. Pueden escanear sus proyectos e identificar código fuente abierto y buscar vulnerabilidades automáticamente. Algunos de estos (FOSSA) ofrecen un nivel gratuito.
El análisis estático de su base de código, incluidos los componentes de código abierto, debería ser una parte estándar de su rigor de desarrollo, de todos modos. Herramientas como Coverity Scan pueden encontrar defectos en su código, como desbordamientos de búfer que pueden generar vulnerabilidades. Incluso aconsejará sobre cómo se pueden rectificar.
Verifique las licencias de código abierto y apéguese a ellas
Asegúrese de comprender las licencias vigentes en el código abierto que utiliza. Hay muchas licencias diferentes, así que comprueba que estás cumpliendo con todos los requisitos. Involucre a su oficial de licencias o cumplimiento, si tiene uno.
El incumplimiento de una licencia de código abierto puede dar lugar a litigios. Los proyectos de código abierto son tan rápidos para responder a las infracciones de licencias como las empresas de software comercial.
Actualice sus componentes de código abierto
Como las comunidades del código abierto que utiliza corrigen las vulnerabilidades, asegúrese de actualizar sus versiones para beneficiarse de esas correcciones. El código abierto utiliza un modelo de "atracción". Anuncian una nueva solución y luego tienes que ir y descargar esa nueva versión. Esto es lo opuesto a mucho software comercial que tiene un modelo "push" donde las actualizaciones se transmiten a los usuarios registrados.
Supervise las páginas del proyecto en busca de anuncios de nuevas versiones y descargue y pruebe las nuevas compilaciones.
El costo del código abierto
El software de código abierto es gratuito, pero conlleva una sobrecarga de gestión y control. Las implicaciones deben comprenderse y controlarse para poder utilizarlo de forma segura y con el mínimo riesgo.
