El código fuente abierto es público, pero ¿lo consulta la gente adecuada?

Las percepciones sobre la seguridad inherente al código fuente abierto y al software de código fuente abierto varían, pero estas percepciones importan.

Por un lado, algunos consideran que el código fuente abierto es menos seguro. Al fin y al cabo, hay menos incentivos comerciales para proteger el código fuente abierto que el código escrito por un proveedor con ánimo de lucro que se juega su reputación.

Por otro lado, existe la opinión de que el código abierto es más seguro simplemente porque está abierto al escrutinio. El argumento es que esta apertura tiene más peso que cualquier incentivo comercial. Con más gente examinando el código fuente abierto, debería ser más fácil identificar los fallos del código fuente abierto.

En este artículo examinamos más de cerca la "apertura" del código fuente abierto y las ventajas de seguridad que debería aportar, pero que a menudo no consigue. También examinaremos la opinión de que, en realidad, son demasiadas las personas equivocadas que examinan el código fuente abierto en busca de oportunidades, y muy pocas las personas adecuadas que trabajan para encontrar y corregir fallos de seguridad.

Contenido:

1. EL CÓDIGO ABIERTO OFRECE ALGUNAS VENTAJAS DE SEGURIDAD
2. LAS EMPRESAS DEPENDEN DEL CÓDIGO ABIERTO, PERO DAN POR SENTADA LA SEGURIDAD...
3. LO QUE ES PEOR, LAS PERSONAS EQUIVOCADAS ESTÁN MIRANDO EL CÓDIGO FUENTE ABIERTO
4. HAY UN "BUEN" ESCRUTINIO, PERO...
5. Incentivos y concienciación

El código abierto ofrece algunas ventajas de seguridad

En primer lugar, existen razones válidas por las que el código fuente abierto se percibe como más seguro en comparación con el código fuente cerrado. Hay argumentos razonables que subrayan por qué, en determinadas circunstancias, el código fuente abierto puede ofrecer ventajas de seguridad.

La idea principal es que, dado que el código fuente abierto es público y está abierto al escrutinio, hay más miradas pendientes del código. Cuando el código se utiliza ampliamente, debería examinarse más a fondo para detectar fallos de seguridad. Por lo tanto, el código debería ser más seguro, ya que los fallos se encontrarán y corregirán más rápidamente. Aunque este puede no ser el caso del código que se utiliza en proyectos más pequeños, en bibliotecas de código o en código altamente especializado.

La segunda ventaja de seguridad del código fuente abierto es que las empresas que lo utilizan pueden reparar más rápidamente los fallos antes de que se conviertan en peligrosos. Más rápidamente, en cualquier caso, que confiando en un proveedor comercial que puede necesitar pasar por extensas pruebas de su código propietario.

Ver estos dos argumentos de forma aislada puede dar la impresión de que el código abierto es mejor opción por sus ventajas de seguridad, pero es un punto de vista que pasa por alto algunos puntos clave.

Las empresas dependen del código abierto, pero dan por sentada la seguridad...

Casi todas las empresas utilizan código abierto a gran escala. Pueden hacerlo explícitamente, utilizando un producto como Red Hat Enterprise Linux, o implícitamente, ya que incluso el software de código cerrado con licencia comercial contiene código abierto.

Un análisis realizado en 2020 por Synopsis reveló que el 99% de las bases de código auditadas para el informe contenían código de fuente abierta. Además, gran parte de este código es antiguo: el 91 % del código auditado para el informe contenía código abierto que no se había actualizado en cuatro años o más.

Esencialmente, no importa si su empresa despliega explícitamente soluciones de código abierto o no, el código abierto está tan omnipresente que debe tomarse la amenaza en serio.

Por desgracia, las empresas a menudo dan por sentada la seguridad del código abierto. Ya sea porque no se dan cuenta de la cantidad de código fuente abierto que soporta sus cargas de trabajo, o debido a los beneficios de seguridad percibidos del código fuente abierto.

Este es un enfoque arriesgado y hay innumerables ejemplos de cómo grandes empresas que prestan servicios clave se ven sorprendidas por un fallo en el código de fuente abierta. Uno de los ejemplos más destacados es la brecha de Equifax en 2017, que expuso registros financieros muy personales de más de 147 millones de personas.

En el caso de la brecha de Equifax, los piratas informáticos explotaron un código vulnerable en Apache Struts 2, un marco utilizado por el portal web de Equifax. La empresa tardó seis semanas en darse cuenta de la brecha, lo que provocó el robo de un gran volumen de datos. Para Equifax, el coste fue inmenso, tanto en términos del acuerdo financiero como, por supuesto, de las consecuencias públicas.

El ejemplo de Equifax no es en absoluto único. Parte del problema reside en el hecho de que los desarrolladores incorporan fácil y rápidamente a sus aplicaciones toda una serie de funciones de código abierto. Desde grandes bloques de funcionalidad hasta bibliotecas individuales.

Lo harían sin un verdadero escrutinio, y a menudo sin catalogar los componentes. El resultado es que las empresas tienen poca idea de qué código fuente abierto dependen sus soluciones tecnológicas. Sin embargo, es casi seguro que el código fuente abierto se esconderá prácticamente en todas partes.

Y lo que es peor, el código fuente abierto lo examinan las personas equivocadas.

Todo el mundo puede examinar el código fuente abierto, incluidos los malos. La omnipresencia del código fuente abierto motiva a los malintencionados a buscar fallos que puedan explotar.

En algunos casos, esta caza es simplemente para obtener un beneficio monetario: los delincuentes quieren encontrar formas de piratear los sistemas para robar información valiosa o pedir un rescate a una empresa. Otros grupos, desde los equipos de amenazas persistentes avanzadas (APT) hasta los agentes estatales, tienen objetivos específicos que pueden alcanzarse explotando los puntos débiles de la seguridad.

La detección de fallos en código fuente abierto de uso generalizado proporciona a estos delincuentes las herramientas que necesitan para introducirse en sistemas que, de otro modo, serían seguros. A veces, los ciberdelincuentes detectan fallos en el código fuente abierto mucho antes de que lo hagan los usuarios o la comunidad del código fuente abierto.

En otras palabras, estas vulnerabilidades de seguridad están en manos de los piratas informáticos, pero los parches y las soluciones aún no están disponibles. Esto da a los delincuentes y a los Estados-nación la oportunidad de explotar los fallos del código fuente abierto antes de que se publiquen los parches y soluciones necesarios.

Hay un "buen" escrutinio, pero...

No se trata de que la comunidad de código abierto ignore los fallos o escriba código por descuido simplemente para olvidarse del código y de dónde se utiliza. Pero el enorme volumen de código abierto en uso -31.000 millones de líneas de código según algunos informes- significa que es casi imposible comprobar a fondo el código en busca de errores.

En la práctica, a menudo vemos viejos fallos en el código fuente abierto que surgen décadas después de que el código fuente abierto se añadiera a una base de código.

Tomemos como ejemplo el fallo libcurl descubierto recientemente en abril de 2021. El código subyacente se añadió a la base de código en agosto de 2000, por lo que la vulnerabilidad ha tardado más de veinte años en hacerse pública. No hay forma de saber qué actores maliciosos tuvieron conocimiento de esta vulnerabilidad a lo largo de las últimas décadas y qué hicieron con ese conocimiento.

Del mismo modo, el error detrás del ampliamente publicitado exploit Heartbleed se encontró 15 años después de que el código se incluyera originalmente en las bibliotecas OpenSSL. De nuevo, no hay forma de saber quién más pudo conocer esta vulnerabilidad antes de que viera la luz.

Simplemente se reduce al hecho de que los buenos no dedican suficiente tiempo a examinar el código fuente abierto. Sí, hay esfuerzos para asegurar el código fuente abierto. Pero estos esfuerzos no son equiparables a los de los actores maliciosos que examinan sistemáticamente el código para encontrar fallos explotables.

Incentivos y sensibilización

El problema de los incentivos para encontrar puntos débiles en el código fuente abierto es conocido por la comunidad de código abierto, los expertos en seguridad y los proveedores que dependen en gran medida del código fuente abierto. Por ello, existen programas diseñados para incentivar a los desarrolladores de código abierto a encontrar errores en el código.

El programa de recompensas por fallos de la UE, por ejemplo, ofrece hasta 25.000 euros a los desarrolladores que detecten vulnerabilidades en proyectos específicos de código abierto. La Fundación Linux también hizo una serie de recomendaciones en su encuesta de colaboradores de código abierto y libre de 2020, en parte porque esa encuesta reveló que los desarrolladores de código abierto consideran que solucionar problemas de seguridad es una tarea desgarradora.

Pero los incentivos nunca cubrirán la brecha de motivación entre los delincuentes, los actores de amenazas y la comunidad de código abierto. Por eso es importante la concienciación.

Para los usuarios empresariales, el primer paso es reconocer que el código fuente abierto está en todas partes. Comprar software a proveedores comerciales que utilizan código propietario no es una póliza de seguros, ya que es muy probable que este código se base en código abierto, como las bibliotecas de código abierto. Sí, los vendedores comerciales tienen un mayor incentivo para asegurar el código, pero en realidad tanto el código propietario como el de código abierto seguirán siendo vulnerables.

Otro paso clave es mantener la capacidad de respuesta. Cuando se descubre un fallo en el código fuente abierto, suele aparecer rápidamente un parche u otro método de mitigación. Las empresas deben aplicar los parches de forma rápida y exhaustiva y, cuando esto sea difícil, considerar el uso de herramientas automatizadas de aplicación de parches que hagan el trabajo pesado, sin interrupciones.

Por último, la seguridad empresarial siempre tendrá que ver con la postura de seguridad. Puede marcar la diferencia entre la rápida mitigación de un ataque en curso y una disculpa pública seis meses después. Hacer suposiciones generales sobre el escrutinio público del código de fuente abierta nunca beneficiará a las operaciones seguras.

En resumen, es difícil decir definitivamente que el código abierto es más o menos seguro que el código cerrado, comercial y propietario. El argumento es sencillamente más complicado. También se han detectado innumerables fallos en el código propietario de código cerrado. No hay que dar por sentado que el código es más seguro por el mero hecho de ser abierto. De por sí, eso no garantiza nada. Se necesita un esfuerzo considerable, los incentivos adecuados y los conocimientos técnicos para asegurar el código, no sólo el acceso a la fuente.

Las empresas deben ser conscientes de que, sí, el código de fuente abierta a menudo se parchea rápidamente y es muy seguro debido a su naturaleza abierta. Pero, por otro lado, el código fuente abierto también puede ocultar vulnerabilidades a plena vista durante décadas.

Continúe leyendo: CÓDIGO ABIERTO: ¿SEGURIDAD EMPRESARIAL CON CÓDIGO ABIERTO?