Código abierto: ¿Seguridad de nivel empresarial con código abierto?

Las organizaciones confían cada vez más en las soluciones de código fuente abierto, aunque no sean conscientes de ello. Pero, ¿se gestiona de forma fiable la seguridad del código fuente abierto? Las grandes organizaciones se centran, con razón, en la utilización de soluciones de software fiables y seguras. A menudo, las soluciones de software más capaces y, de hecho, las más seguras son las de código abierto y gratuito.

Incluso cuando las organizaciones siempre pagan por el software, el software con licencia comercial suele depender de bibliotecas de código abierto para algunas funcionalidades - esta tira cómica de XKCD es un potente resumen de cómo funcionan estas dependencias.

Pero la seguridad de los programas informáticos de código abierto es motivo de preocupación, sobre todo porque a menudo no hay una parte responsable en última instancia de la seguridad de una solución de código abierto.

No es de extrañar entonces que una encuesta de la Fundación Linux de 2020 hiciera un esfuerzo por examinar la seguridad del software de código abierto. En este artículo analizamos algunos de los resultados de dicha encuesta. Examinaremos estos resultados en el contexto de una cuestión importante: si las soluciones de código abierto pueden ofrecer operaciones seguras en el entorno empresarial.

Contenido:
1. ¿Qué impulsa el desarrollo de código abierto?
2. Imperativos comerciales detrás del desarrollo de código abierto
3. Los incentivos importan, pero puede que no haya nadie que los incentive... Los incentivos son importantes, pero puede que no haya nadie a quien incentivar...
4. ¿Es importante el código abierto para las empresas? ¿Importa el código abierto para las empresas?
5. Predominio del código abierto en el entorno empresarial
6. La seguridad no viene determinada por el modelo de código fuente. La seguridad no viene determinada por el modelo de código fuente
7.
8. Métodos prácticos para mejorar la seguridad del software Métodos prácticos para mejorar la seguridad del software
9. 9. Considere la aplicación de parches automatizados en tiempo real para aumentar la seguridad del código abierto
10. Maneje el código fuente abierto como cualquier otro código

¿Qué impulsa el desarrollo de código abierto?

Sabemos qué impulsa el desarrollo de software comercial de código cerrado. Es pura y simplemente el beneficio. En teoría, los vendedores de software comercial invertirán tiempo y esfuerzo en asegurar su software en el momento de su lanzamiento.

Los vendedores también suelen responder rápidamente a los problemas de seguridad informática detectados tras la publicación del código. De nuevo, la motivación es simple. Un software seguro es un software rentable, y ningún vendedor comercial querría tomarse libertades con la seguridad del software, ya que ello provocaría rápidamente daños a la reputación y una caída de los beneficios.

Las cosas son un poco más complicadas cuando se trata de software de código abierto. Por lo general, el desarrollo de software de código abierto no se rige por imperativos comerciales coordinados, y los envíos a repositorios de código abierto no suelen dar lugar a un pago directo por el envío.

Las motivaciones de las contribuciones son importantes porque indican el nivel de cuidado que se presta a la seguridad del software. El informe de la Fundación Linux sugiere tres razones típicas por las que los desarrolladores contribuyen al código fuente abierto:

• Un desarrollador descubrió un problema que necesitaba solucionar en una solución de código abierto de la que dependía. O un desarrollador necesita añadir una función específica a la solución de código abierto que utiliza.
• Como ejercicio de aprendizaje, los desarrolladores contribuyen al código abierto para poner en práctica sus competencias y aprender más sobre un proyecto de código abierto.
• Para algunos desarrolladores, contribuir a proyectos de código abierto tiene el simple encanto de ser un trabajo de programación estimulante y gratificante.

Contribuir a la seguridad del software de código abierto no ocupa un lugar destacado en la lista. De hecho, los colaboradores sugirieron que trabajar en cuestiones de seguridad del código fuente abierto una tarea agotadora e ingrata.

Imperativos comerciales detrás del desarrollo de código abierto

La encuesta de la Fundación Linux también destacó otro importante motor del desarrollo de código abierto: los requisitos comerciales. Según la encuesta, es habitual que los desarrolladores que contribuyen al código fuente abierto reciban una remuneración por hacerlo; el 52% de los desarrolladores que respondieron a la encuesta declararon que se les pagaba por contribuir a un proyecto de código fuente abierto.

En otras palabras, cerca de la mitad de los encuestados sugirió que un empleador de algún tipo -ya sea una institución o una empresa comercial- pagaba por la realización del trabajo. Es una gran proporción de encuestados, y refleja el hecho de que a veces es una necesidad comercial la que impulsa las contribuciones de código abierto.

Esta necesidad puede ser una nueva función, pero también puede ocurrir que una organización comercial se haya percatado de un fallo en el código abierto y pague a un desarrollador para que lo solucione.

Esto es un buen augurio para la seguridad del software de código abierto, pero también sugiere que, a menos que un operador comercial encuentre un fallo y tenga el incentivo de corregirlo, es posible que el fallo nunca se corrija, dado que los desarrolladores de software de código abierto no están tan motivados para trabajar en la seguridad de este tipo de software.

Los incentivos importan, pero puede que no haya nadie a quien incentivar...

No pretendemos precipitarnos a la hora de juzgar. Hay miles de millones de líneas de código abierto, muchas de las cuales se escribieron sin ningún tipo de remuneración, ya que muchos desarrolladores analizan, codifican y corrigen por puro amor al modelo de código abierto.

No obstante, está claro que los incentivos -comerciales o de otro tipo- son útiles para acelerar la detección y corrección de fallos de seguridad.. Pero incluso los incentivos podrían no ser suficientes.

Sabemos que algunos fallos de código abierto pueden encontrarse en código muy antiguo - el fallo recientemente descubierto en libcurl por ejemplo, tiene décadas de antigüedad. El problema es que incluso con los incentivos adecuados para reparar el código, encontrar a los desarrolladores que lo hagan puede ser todo un reto.

Los proyectos de código abierto maduran y pasan a un segundo plano con el tiempo, aunque el código que los sustenta siga utilizándose a diario. Esto crea un problema a la hora de encontrar desarrolladores, ya que los desarrolladores originales se han ido a otros proyectos, dejando atrás un número limitado de desarrolladores que todavía son capaces de calibrar la corrección y el valor del código aportado al proyecto.

Es un problema común en muchos proyectos de alto perfil que luchan por encontrar desarrolladores con las cualificaciones necesarias para contribuir. También es un problema cuando se trata del núcleo de Linux.. Esto significa que algunos proyectos dependido cada vez más de desarrolladores pagados para avanzar en aspectos clave de un proyecto, como la seguridad.

¿Es importante el código abierto para las empresas?

Está claro que la seguridad del software de código abierto presenta bastantes matices, pero ¿importa realmente a los usuarios empresariales? Al fin y al cabo, las grandes organizaciones pueden permitirse pagar por un software seguro.

De nuevo, es complicado. Para empezar, las capacidades del software de código abierto pueden superar las del software comercial y, por esa razón, las empresas pueden optar por una solución de código abierto, aunque esa solución se ofrezca en condiciones comerciales.

También es cierto que el software comercial contiene a menudo elementos de software de código abierto, por ejemplo en las bibliotecas. Piense en PuTTy, una herramienta de uso común que suele incluirse en soluciones comerciales, pero que en sí misma fue víctima de un fallo descubierto recientemente.

O OpenSSL, la solución SSL abierta que causó grandes olas cuando se descubrió un fallo de seguridad - un fallo de seguridad que se niega a desaparecer.

Predominio del código abierto en el entorno empresarial

La cuestión es que incluso las empresas que dependen exclusivamente de software con licencia comercial tienen muchas probabilidades de depender de código abierto en alguna parte.

No es sólo una afirmación. Un estudio de Gartner ampliamente citado sugiere que el 95% de las operaciones empresariales utilizan software de código abierto para alguna parte de sus operaciones críticas. Hay varias razones para ello, pero rara vez se debe a un esfuerzo por ahorrar dinero.

Sí, el software de código abierto es gratuito en principio, pero las soluciones de nivel empresarial rara vez lo son, ya que las grandes organizaciones suelen depender de soluciones de código abierto como parte de intensos esfuerzos de desarrollo, y a menudo vinculan el software de código abierto a costosos contratos de asistencia.

La razón por la que las empresas a veces eligen explícitamente software de código abierto "libre" es que en muchos casos el código abierto puede ofrecer las soluciones más capaces.

Por último, como hemos señalado en la sección anterior, el código abierto está arraigado incluso en una solución comercial de código cerrado. De hecho, se puede argumentar que el código fuente abierto está lo suficientemente extendido como para que las organizaciones puedan asumir que el código abierto se utiliza en una solución, independientemente de la fuente de la solución que se implante.

La seguridad no la determina el modelo de origen

El código fuente abierto es público, por lo que, en teoría, más personas pueden y van a examinar este código y, por lo tanto, hay más oportunidades de detectar fallos. Sin embargo, la realidad puede ser diferente, ya que fallos como el de OpenSSL que hemos mencionado antes tardan años en descubrirse.

Y, como ya hemos explicado, la motivación de los desarrolladores de código abierto para buscar y encontrar fallos en el código abierto puede ser limitada.

Al mismo tiempo, el hecho de que el software comercial de código cerrado obedezca a un afán de lucro no significa que sea más seguro que el código abierto. No hay garantía de que un proveedor despliegue investigadores de seguridad para examinar el código en busca de fallos y siempre existe el riesgo de que los equipos de proyecto se apresuren a codificar para intentar terminar un proyecto en un plazo determinado. Además, una vez terminado, puede que el código nunca se revise.

Así pues, aunque en teoría el código fuente abierto está más abierto al escrutinio y, por tanto, es más seguro, no hay garantías de que lo examinen las personas adecuadas. Por otro lado, tampoco hay garantías de que los proveedores de software comercial se tomen en serio su responsabilidad en materia de seguridad.

Por encima de todo, los desarrolladores siempre pasan cosas por alto y siempre cometen errores, independientemente de que cobren o no y de la parte que pague al desarrollador.

Llenar el vacío de seguridad del código abierto

No importa si su organización considera que la seguridad del software de código abierto es peor o mejor que la del software con licencia comercial. El hecho es que existen lagunas en la seguridad del software de código abierto y que la mayoría de las organizaciones dependen del software de código abierto de alguna manera. Por lo tanto, la seguridad del software de código abierto importa, y punto.

Sí, la seguridad del software es responsabilidad de su organización, y en la siguiente sección trataremos algunos métodos de eficacia probada. Pero la comunidad de código abierto y los usuarios de software de código abierto deben dar los primeros pasos en materia de seguridad del código abierto. El informe de la Fundación Linux hacía algunas sugerencias importantes a este respecto:

• Debe darse prioridad a la financiación para que los desarrolladores tengan un incentivo para trabajar en la seguridad del software de código abierto, incluso en auditorías periódicas del código abierto más crítico.
• La Fundación Linux también sugiere que el código fuente abierto que haya demostrado repetidamente ser vulnerable se reescriba desde cero. Por ejemplo, convirtiendo el código de un lenguaje no seguro para la memoria (como C o C++) a un lenguaje seguro para la memoria (como Python o JavaScript).
• Además de la financiación, se debería incentivar a los desarrolladores mediante programas de distintivos y a través de la tutoría para ayudar a impulsar la importancia de la seguridad del software en la comunidad de código abierto.
• Por último, la Fundación Linux sugirió que los vendedores comerciales hicieran de los conocimientos sobre seguridad del software un requisito previo a la hora de contratar desarrolladores de código abierto, al tiempo que ofrecieran formación continua para capacitar a sus desarrolladores con el fin de proporcionar una base de apoyo al desarrollo de software seguro.

A largo plazo, la única forma de que el software de código abierto sea más seguro de lo que es actualmente será que todas las partes vuelvan a centrarse en la seguridad y, al mismo tiempo, ofrezcan los incentivos adecuados a los desarrolladores que trabajan en el código. Los incentivos, tal y como están, no son suficientes.

Métodos prácticos para mejorar la seguridad del software

Existen lagunas en la seguridad del software de código abierto, pero hay una serie de herramientas disponibles para ayudar a solventarlas. Además, en última instancia, la seguridad del software es responsabilidad de su organización. Sugerimos los siguientes puntos:

• Aplique sistemáticamente buenas prácticas, como la autenticación multifactor (MFA) y la seguridad de contraseñas seguras. La gestión de credenciales y de permisos también es fundamental.
• La supervisión y las pruebas le ayudarán a identificar intrusos y fallos en su perfil de seguridad para que pueda detener las intrusiones antes de que tengan consecuencias graves.
• Conozca las herramientas en las que confía e intente comprender también los componentes básicos subyacentes, incluidas las bibliotecas y dependencias, ya que a menudo los verdaderos riesgos no están a la vista.

Sin embargo, podría decirse que el elemento más importante de la seguridad del software es la aplicación de parches. La aplicación constante y exhaustiva de parches protege sus soluciones frente a vulnerabilidades conocidas y es igual de eficaz tanto si utiliza software libre como si tiene una licencia comercial.

Dicho esto, parchear de forma coherente simplemente no es fácil. La aplicación de parches puede llevar mucho tiempo y, a menudo, los equipos se limitan a parchear las vulnerabilidades de mayor prioridad, dejando expuestos muchos otros fallos. El hecho de que la aplicación de parches a menudo requiera un reinicio o reinicio no ayuda, en aras de la disponibilidad los equipos a menudo deciden no parchear según lo previsto - sólo parchear si hay una vulnerabilidad crítica.

Considere la posibilidad de aplicar parches automáticos en directo para reforzar la seguridad del código abierto

La aplicación de parches es fundamental, pero a menudo no es todo lo eficaz que debería. Los parches de kernel automatizados y en tiempo real de TuxCare cubrirán una gran laguna en la seguridad del código abierto al garantizar que sus servidores estén siempre protegidos frente a las vulnerabilidades, sin la consiguiente interrupción de los servicios.

Los equipos de desarrollo de código abierto y las contribuciones individuales carecen de motivación e incentivos para asegurar plenamente el software al que contribuyen. Y, como sabemos, errar es humano: siempre se cometerán errores.

La Fundación Linux ha hecho varias recomendaciones sólidas que probablemente mejorarán la seguridad del código abierto, pero en un futuro previsible los fallos seguirán apareciendo en el código, sólo para ser encontrados y parcheados. Los parches importan.

Maneje el código fuente abierto como cualquier otro código

En conclusión, los usuarios empresariales casi siempre dependen del código fuente abierto, ya sea directa o indirectamente a través de bibliotecas. Aunque el código fuente abierto no es intrínsecamente inseguro, hay consideraciones de seguridad únicas cuando se trata de código fuente abierto.

La concienciación es el primer paso, y la aplicación de parches en vivo puede ser una acción de apoyo útil. En otras palabras, el código fuente abierto puede ser muy seguro, tan seguro como el código fuente cerrado de un proveedor comercial. Todo depende de la postura de seguridad de su organización.