A fondo: ¿Cómo de seguro es el software open source?

¿Software propietario o software open source? Los argumentos a favor y en contra de cada una de estas opciones se han ido amontonando con el paso de los años de la mano de usuarios, creadores y opinadores en general. Su precio ha marcado el debate. Así como el soporte. El mantenimiento. Su estabilidad. Su rendimiento. Su funcionalidad. La compatibilidad. La flexibilidad. La libertad. La fiabilidad. Su calidad. Y, muy importante, su seguridad. Una de las cuestiones sobre las que se ha incidido con especial insistencia es aquella que plantea si las garantías de seguridad de estas dos clases de software, tradicionalmente enfrentadas, son las mismas. La afirmación acerca de que las prácticas de desarrollo más cerradas también son las más seguras, en comparación con aquellos entornos donde existe mayor libertad de movimientos y la participación de diferentes miembros de la comunidad, se ha convertido en un mito que en la actualidad está superado a medias.

Podría pensarse que los prejuicios son cosa del pasado, pero cada vez que un programa de código abierto se cuela entre los activos de una empresa o en el ámbito de la Administración Pública se genera sorpresa. Que en ciertas instancias opten por lo open basta para hablar de bombazo. ¿Por qué? ¿Puede entrañar riesgos esta decisión? ¿Están justificados los recelos de algunas personas acerca del software abierto? “Con respecto a la seguridad del software abierto, los miedos son comprensibles por el posible desconocimiento de los mecanismos de protección existentes, pero no están justificados: el software abierto puede ser tan seguro o más que el software propietario”, afirma en declaraciones a Silicon.es Rafael Godinez, Solution Architects Manager de Red Hat Iberia. “El nivel de seguridad ofrecido por un conjunto de programas no depende exclusivamente del modelo de desarrollo del mismo”, apunta Godinez. La pauta que ha marcado su desarrollo no garantiza que un tipo de software sea “más seguro que otro creado” de forma distinta. De hecho, “todo el software, independientemente de como haya sido desarrollado, está expuesto a vulnerabilidades y fallos ocultos”.

Los miembros de la industria de seguridad piensan de forma similar. Silicon.es ha hablado con compañías de sobra conocidas como Kaspersky Lab, Avast y Panda, y todas ellas huyen de los síes y los noes absolutos. “Creo que es todo una cuestión de percepción. Si pagas por algo, por lo general esperas que sea mejor que aquello que obtienes de manera gratuita. La razón por la que a las empresas les ‘asusta’ el código abierto puede incluir problemas de soporte”, explica Michal Salat, Threat Intelligence Manager de Avast. Esto es, “la sensación de que el soporte del producto es realizado por parte de un grupo poco organizado de personas, ya sea en su tiempo libre o en cooperación con otros productos”. Además, “si ya cuentas con una pieza de software creada por una empresa, es más fácil adoptar otra que proviene de la misma compañía, porque suelen ser probadas para trabajar juntas. En el caso del software open source, siempre habrá casos en los que la interconexión no es 100 % fluida y a veces se necesita software reutilizable adicional”. Y eso podría echar a la gente para atrás.

En todo caso, “si hay una solución de código abierto completa que funciona, no veo problema en usarla”, dice Salata, que pone como ejemplo de productos que deberían ofrecer tranquilidad los de la Apache Software Foundation. Luis Corrons, Director Técnico de PandaLabs, cree que los miedos son “injustificados para proyectos bien auditados” pero “justificados, seguramente, para proyectos pequeños o con poca madurez de desarrollo”. Esto quiere decir que, de tener que elegir, “no implantaría en mi empresa una solución abierta poco probada, muy novedosa, cuyos programadores no estén involucrados con el proyecto”. El caso es que “tampoco metería un software propietario obsoleto como Windows XP”, compara Corrons. Mientras, Vicente Díaz, que es analista principal de Kaspersky Lab, incide en que el hecho de estar abierto no confirma “necesariamente que sea más seguro” ni “más inseguro. Sí que es posible que el poder acceder al código pueda suponer una ventaja por parte de un atacante al tener disponible más fuentes para ampliar su conocimiento del objetivo, pero al mismo tiempo la seguridad a través de oscuridad no es ninguna garantía”.

Diferencias entre abierto y cerrado

La conclusiones taxativas no van con esta controversia. Sin embargo, ¿existe alguna diferencia entre soluciones abiertas y cerradas en términos de seguridad? “En general, no”, responde Salat. “No hay ninguna diferencia entre el desarrollo de código abierto y el desarrollo propietario aparte de que los códigos open source se liberan al público”. Así que “si el software está mal codificado, será inseguro en ambos casos”, dice. Para él buscar enfrentamientos a este nivel es lo mismo que preguntarse “cuál es la diferencia entre un coche del que tienes su dibujo técnico y otro para el que no tienes copia de plano”. En opinión de Vicente Díaz tampoco “existen diferencias relevantes por el” mero “hecho de que un código sea abierto o no, sino que” los cambios entre ecosistemas “son más inherentes a aspectos del desarrollo que hay detrás” de ambos. Aunque algo se puede rascar. Algo que separa al software propietario del de código abierto sería que, en el primero de ellos, las “vulnerabilidades pueden pasar desapercibidas a los usuarios durante más tiempo y sin embargo, estar siendo explotadas por quienes las conocen”, señala Rafael Godinez.

El representante de Red Hat añade que “los fabricantes de software propietario pueden ocultar la existencia de una vulnerabilidad tanto como deseen por diferentes motivos: para proteger una imagen de marca, durante el tiempo necesario para desarrollar la corrección correspondiente, o para que ciertas operaciones de sus programas se puedan efectuar con menos dificultades”. Godinez piensa que en el código abierto, “por su naturaleza, no es posible ocultar ni los posibles errores de programación ni las funcionalidades ocultas a los ojos de los usuarios. Por tanto, permite la detección más temprana de los posibles fallos y que éstos sean corregidos en tiempo récord una vez descubiertos”. Cuando “hay un problema de seguridad localizado, en las soluciones abiertas los parches, actualizaciones, correcciones” y demás “pueden involucrar a más gente. Y al ser visibles implican mayor presión para buscar correcciones”, reconoce desde su condición de experto en seguridad Luis Corrons. “El software propietario se escuda” en cambio en una “supuesta protección adicional derivada de que nadie más tenga acceso a los fuentes”. Si bien “hoy en día esto no suele ser así debido a la facilidad de obtener la funcionalidad de un software con herramientas de ingeniería inversa”.

Obviamente, “esto depende de lo crítico que sea el problema y del software en sí: no es lo mismo un LibreOffice con una vulnerabilidad crítica que una utilidad de uso marginal y cuatro descargas, desarrollada por un programador en sus ratos libres”, determina Luis Corrons. “Por otro lado, desde siempre el software propietario se ha servido de la seguridad por ocultación”. Es decir, en que “si no te digo cómo funciona por dentro, difícilmente vas a poder buscarle las cosquillas a mi software”. Lo que ocurre es que “hay cada vez más personas buscando vulnerabilidades y problemas en todo tipo de software y también más herramientas para automatizar estas pruebas”, obligando a todo tipo de desarrolladores, de software abierto y propietario, a mantenerse alerta. “Además”, advierte el Director Técnico de PandaLabs, “suele ser más jugoso encontrar una vulnerabilidad en un software propietario que en uno libre”.

En los desarrollos open source, la seguridad “se garantiza con auditorías del código”, con “buenas prácticas de programación”, al “buscar un buen resultado antes que un resultado rápido” y con “financiación apropiada”, enumera Luis Corrons. ¿Y les beneficia la colaboración? “Que estén abiertos puede ayudar”, aprecian desde Panda, aunque matizando que “en ambos casos, el problema de la seguridad depende de factores externos”. Kaspersky Lab tampoco ve la colaboración como beneficio definitivo. “Garantizar la seguridad es imposible”, alega su analista Vicente Díaz. Así que la colaboración será o no “una ventaja en función de cómo se gestione. Es decir, no es lo mismo una colaboración voluntaria donde alguien puede o no realizar una comprobación, que una colaboración exhaustiva como la que ocurren en algunos proyectos”, razona Díaz. El Threat Intelligence Manager de Avast, Michal Salat, agrega que, “en algunas ocasiones, los parches entregados acaban rechazados por los propietarios del proyecto”, y esto le perjudica en “facilidad de uso y seguridad”.

Lo que sí permite el desarrollo colaborativo es “que más ojos revisen el código y sea mucho más difícil que pasen desapercibidos fallos de programación o funcionalidades ocultas”, destaca el Solution Architects Manager de Red Hat, Rafael Godinez. “Los usuarios del software, por regla general, son mucho más numerosos que los desarrolladores de éste, y frecuentemente encuentran la forma de utilizar los programas de formas distintas a las que habían sido concebidas por sus creadores. Si los usuarios pueden ver el código e influir”, justifica Godinez su postura, “la adaptación a nuevos casos de uso o la eliminación de comportamientos indeseados se facilita”. De ahí que “la definición de estándares comunes” se trate como “algo inherente al desarrollo de código abierto”, poniendo de acuerdo “a sectores enteros” para construir “software de manera ágil y segura”. ¿Y qué pasa con el método de distribución online de este software? ¿Es un riesgo? Simplemente “forma parte del modo de ser del desarrollador de código abierto para proyectos genéricos”, indica el portavoz de PandaLabs, Luis Corrons. Y, de una forma u otra, “una vulnerabilidad está presente o no lo está”, argumenta el de Avast, Michal Salat.

“La distribución es independiente de la seguridad”, incide el analista principal de Kaspersky Lab, Vicente Díaz. “Las nuevas plataformas colaborativas como GitHub han proporcionado facilidad a la hora de comprobar cualquier aspecto puntual de un proyecto por parte de cualquiera, lo que es muy positivo. No obstante, debemos tener siempre presentes una serie de precauciones como comprobar los hashes una vez se completa la descarga, o no instalar a ciegas de repositorios de terceros”. Representando a Red Hat, Rafael Godinez aclara que “existen mecanismos para establecer la correspondencia entre el código fuente, inspeccionable, y el programa que se puede emplear en nuestros entornos productivos, que no siempre es legible directamente por un humano” y que “gracias al uso de estándares comunes” se facilita “la automatización de los procesos de producción de software a escala”.

“La industrialización del proceso de generación del código ejecutable a partir del código inspeccionable con tests automatizados reduce la posibilidad de alteraciones, manteniendo la integridad sobre el código original desde el que se construye, y garantizando que el comportamiento final del programa es el descrito en el código fuente verificado”, clarifica el Solution Architects Manager de la compañía del sombrero rojo. “Del mismo modo”, tal y como recuerda este miembro de la industria tecnológica, “mediante la aplicación de firmas y métodos de cifrado sobre el contenido y catálogo se construyen repositorios confiables” que “se pueden utilizar con total tranquilidad para el aprovisionamiento de software abierto certificado y de calidad contrastada y para su funcionamiento en sistemas productivos, evitando la introducción involuntaria de programas alterados por terceros”.

El estado actual del open source

¿Cuál es el estado actual del software open source? ¿Hay suficientes metodologías para validar las prácticas que siguen los desarrolladores? ¿Qué estándares miden a día de hoy la calidad de cada proyecto? “El software open source se encuentra en estado de madurez, implantado en sistemas en producción de todo tipo y en todo el mundo. Hoy en día no cabría concebir nuestra vida cotidiana sin software open source en sistemas bancarios, telecomunicaciones, sanitarios, transporte, entretenimiento, multimedia, domótica, automoción…”, expone el propio Rafael Godinez. Justo esta expansión en “sistemas críticos para nuestra vida diaria” es la que “hace necesaria la aplicación cuidadosa de las mejores prácticas aprendidas a lo largo del tiempo para la producción de software open source de manera colaborativa, segura y eficiente”. Sería clave “estar abierto a la incorporación de nuevos estándares y metodologías que ayuden a dotar de mayor agilidad a los desarrollos, sin perder las características de seguridad y fiabilidad que son exigibles”.

Red Hat, como integrante de este sector, apuesta por actuar “de manera proactiva” y perfeccionar sus prácticas “en el equipo de Red Hat Product Security”. En este sentido, Luis Corrons aprecia que “el software open source, en ocasiones, está avalado por empresas punteras en las técnicas de calidad”. Al mismo tiempo, “es una práctica habitual en la mayoría de proyectos open source que el código subido sea revisado por otros desarrolladores antes de ser aceptado para una versión. También es muy habitual”, apunta, que el “más moderno se entregue junto con un entorno de pruebas unitarias lanzadas tras el proceso de compilación para verificar los casos de uso más relevantes”. Unos casos que “son mantenidos por la comunidad de desarrollo como parte del proceso de entrega de software”, concluye Corrons. A la hora de evaluar las prácticas open source, Michal Salat menciona que “hay muchos proyectos de propósito único que son publicados en Internet y a los que nadie presta nunca mucha atención” y otros que se utilizan “de forma más amplia” cuyos niveles de seguridad “son comparables al software propietario”.

“Existen metodologías y prácticas de seguridad que son ampliamente conocidas, pero hay que seguirlas con el fin de escribir código que sea seguro” y aquí “es importante tener en cuenta que seguir metodologías o normas de seguridad no es un requisito al escribir código fuente propietario ni tampoco de código abierto”, recuerda Salat. “Las metodologías y herramientas existen, pero el aplicarlas o no depende de cada uno de los proyectos: no por ser open source implica que se usen, o no”, concuerda Vicente Díaz, que sin embargo advierte de que algunos estándares internacionales sí “son certificaciones obligatorias para poder desplegar software en ciertos entornos, como gobiernos”. Y a pesar de que la calidad final dependerá del objetivo, “todos los productos se someten a una batería continua de pruebas en los que rendimiento, seguridad, estabilidad” y otras pautas “se puntúan constantemente, y se realizan pruebas exhaustivas de aspectos como compatibilidad antes de publicar cualquier actualización”, subraya Díaz. “En cualquier caso no existe ni metodología perfecta ni tampoco herramientas que garanticen la seguridad. Se trata de un proceso continuo en el que se recomienda trabajar con terceros para que validen los resultados”.

Es posible medir la calidad de un proyecto de software “desde muchos aspectos, algunos clásicos como la cobertura de código de las pruebas realizadas y otros aspectos más modernos como la cantidad de revisiones de código realizadas dentro del equipo de desarrollo”, elabora Luis Corrons. “La tendencia en el mundo del desarrollo de software es automatizar los casos de prueba para asegurar que la cobertura de código se mantiene porcentualmente estable mientras el proyecto crece”, manteniendo la ‘salud’ del código entregado y, lo que es más importante”, pudiendo “verificar que una nueva entrega no afecta negativamente al código existente. Las revisiones de código dentro de un equipo de desarrollo ayudan a mantener una línea de desarrollo coherente que beneficia a la evolución de la solución”, opina Corrons, lo que significa compartir puntos de vista y experiencia para “homogeneizar la línea de desarrollo existente”.

“Un aspecto clave de la seguridad en el software no es sólo la producción de código seguro”, considera Rafael Godinez, “sino la capacidad de detectar y corregir las vulnerabilidades en el menor tiempo posible, y de hacer posible la aplicación de esas correcciones sin que ello suponga una pérdida de servicio para los usuarios finales. Para que esto sea posible se precisa de la definición y aplicación de estándares tanto en el desarrollo del software, como en los mecanismos de detección y comunicación de vulnerabilidades, y el diseño y producción de las correcciones necesarias”. Entre estos mecanismos de medición y análisis se encuentran CVRF, OVAL, SCAP y CVE, cuyo uso “permite trabajar de manera coordinada y extremadamente ágil a través de todos los miembros de la comunidad de manera transparente, desde los desarrolladores al cliente final”, asevera Godinez, que estima que se puede alcanzar un “98 % de vulnerabilidades críticas corregidas en menos de un día, con una media de 0,6 días por corrección realizada”.

Michal Salat ratifica que “existen normas de programación, junto con recomendaciones disponibles para desarrolladores de código abierto, como por ejemplo las de SEI CERT”. A esto hay que sumar el reciente programa que ha anunciado The Linux Foundation a través de su proyecto Core Infrastructure Initiative, de nombre CII Best Practices Badges. De carácter gratuito, dicho programa cuenta con una aplicación online y tiene por objetivo contribuir a aclarar dudas. No en vano, permite determinar si los desarrollos de código abierto que se someten a su escrutinio cumplen con una serie de buenas prácticas. Es decir, si son o no seguros. Todos aquellos que pasan su corte reciben una insignia identificativa que ratifica a primera vista que se ha empleado una metodología de fiar. Sus responsables defienden que “los proyectos de código abierto ponen a menudo en acción muy buenas prácticas de seguridad”, pero que a pesar de ello “necesitan una manera de validarlas frente a las mejores prácticas de la industria y de la comunidad, y asegurar que siempre están mejorando”.

Ni más ni menos fiable

Así las cosas, ¿puede revertirse la historia para afirmar que el software open source es más seguro que el resto? “Depende”, sostiene Vicente Díaz, analista de Kaspersky Lab. “La ventaja de que el código abierto pueda ser auditado de forma independiente por terceros no equivale a la ausencia de vulnerabilidades, como se puede comprobar en múltiples proyectos abiertos. Muchas veces no es una cuestión de voluntad, sino de complejidad y de capacidad de detección de las mismas”. Díaz apunta, además, que “el código propietario también se audita por terceras partes de forma continua y se somete a estrictos controles de calidad”. Lo único seguro es que “es muy difícil generalizar”, observa Michal Salat, Threat Intelligence Manager de Avast. Grandes exponente “como Android (AOSP), el servidor Apache Web y otros grandes proyectos de código abierto han demostrado que es posible desarrollar software open source de calidad, utilizado por muchas empresas en todo el mundo”, que convive con “un montón de software propietario como Flash, por ejemplo, que es tristemente célebre por las vulnerabilidades y que desarrollan grandes empresas”. Pero “el nivel de seguridad es, en general, comparable” entre lo abierto y lo cerrado.

“Los términos seguro/inseguro no se puede asociar a propietario/abierto ni viceversa”, descarta Luis Corrons. “Son otros los factores involucrados: calidad del código, confianza en los desarrolladores, pruebas realizadas, comprobaciones de seguridad en el propio código, etc. Es cierto que tener los fuentes de un proyecto puede ayudar a localizar más fácilmente problemas potenciales pero el objetivo no es ése, sino compartir conocimiento, reutilizar, hacer comunidad…”, detalla Corrons, que no olvida “casos sangrantes de vulnerabilidades en ambos modos de desarrollo”. Ahí está OpenSSL, sin ir más lejos. “No obstante, el mundo actual es cada vez más complejo y la evolución de los entornos de TI así lo evidencia”, apostilla Rafael Godinez, Solution Architects Manager de Red Hat Iberia, por lo que la seguridad “ya no puede depender de un número reducido de actores”. Se reclama colaboración para “una mayor eficiencia en la detección”, corrección y “construcción de sistemas que sean seguros por diseño, no como una capacidad añadida”, insiste Godinez. Al final se busca que “cada capa esté construida con la seguridad como principio integrante”, creando “entre todos el mejor software que se adapte a las necesidades de cada uno y del conjunto”.