Informe: vulnerabilidades de código abierto desenfrenadas en proyectos populares

 el código abierto es más popular y más vulnerable a los problemas de seguridad como consecuencia

Las vulnerabilidades de código abierto aumentaron casi un 50 por ciento en 2019 durante el año anterior, según un informe publicado el jueves.

Vulnerabilidades comunes calificadas como altas o la gravedad crítica se encontró en todos los proyectos de código abierto más populares, según el informe anual de WhiteSource 2020, "El estado de las vulnerabilidades de seguridad de código abierto".

Se espera que la tasa de vulnerabilidad continúe aumentando.

Como abierto El uso de la fuente continúa creciendo, también lo hace el número de ojos centrados en la investigación de seguridad de código abierto. Esto resultó en un número récord de vulnerabilidades de seguridad de código abierto publicadas el año pasado, según el informe.

El informe cubre vulnerabilidades de código abierto publicadas en 2019 junto con vulnerabilidades de seguridad en lenguajes de programación populares. También revisa los CWE más comunes, o enumeraciones de debilidades comunes, en los últimos años. Pesa el papel de la puntuación y la gravedad de las vulnerabilidades de código abierto, y los tipos de vulnerabilidades que se encuentran en los proyectos de código abierto más populares.

El número de vulnerabilidades de software de código abierto divulgadas en 2019 se disparó a más de 6,000 vulnerabilidades reportadas, según la base de datos WhiteSource. WhiteSource agregó sus resultados de investigación de la National Vulnerability Database (NVD), docenas de avisos de seguridad, bases de datos de vulnerabilidad revisadas por pares y rastreadores de problemas de código abierto populares.

Los investigadores atribuyeron este aumento sin precedentes al aumento de la conciencia del código abierto seguridad tras la adopción generalizada de componentes de código abierto y el crecimiento masivo de la comunidad de código abierto en los últimos años. Los investigadores también vieron un impacto de la atención de los medios dirigida a las recientes violaciones de datos.

"El fuerte aumento en el número de nuevas vulnerabilidades de seguridad de código abierto publicadas en 2019 significa que toda la industria, junto con la comunidad de código abierto, está prestando más atención y "Invertir recursos y esfuerzos en descubrir, corregir y reportar vulnerabilidades en componentes de código abierto", dijo Rhys Arkins, director de gestión de productos en WhiteSource.

Hallazgos clave

El uso de código abierto y la investigación continúa proliferando. Junto con la creciente popularidad de los proyectos de código abierto, el número de vulnerabilidades de código abierto reportadas continúa creciendo.

Más del 85 por ciento de las vulnerabilidades se publican con una solución, pero no todas las soluciones se informan en el NVD. Solo el 84 por ciento de las vulnerabilidades de código abierto conocidas finalmente aparecen en el NVD.

El NVD es el repositorio del gobierno de los Estados Unidos de datos de gestión de vulnerabilidades basados ​​en estándares basados ​​en el Protocolo de Automatización de Contenido de Seguridad (SCAP). Estos datos permiten la automatización de la gestión de vulnerabilidades, la medición de seguridad y el cumplimiento.

Solo el 29 por ciento de todas las vulnerabilidades de código abierto informadas fuera del NVD finalmente se publican en él. Ese hallazgo se basa en la base de datos de WhiteSource.

Más del 55 por ciento de las vulnerabilidades de código abierto reportadas en 2019 se clasificaron como de gravedad alta o crítica. Este gran número impacta en la capacidad de los equipos de software para priorizar la corrección de vulnerabilidades.

CWE-79 (secuencias de comandos de sitios cruzados), CWE-20 (validación de entrada incorrecta) y CWE-200 (exposición de información) son los tres principales CWE para Java, JS, php y vulnerabilidades de Python.

Resultados sin amenaza para la confiabilidad

Es poco probable que este informe debilite la confianza empresarial en el software de código abierto, dijo Arkins de WhiteSource a LinuxInsider. El uso de código abierto se ha convertido en una práctica estándar en todas las industrias y verticales. El informe no debería cambiar eso ni hacer que las organizaciones cuestionen la seguridad de los componentes de código abierto.

"Por el contrario, el aumento en el número de vulnerabilidades de seguridad de código abierto reportadas es en realidad una buena noticia", dijo. "Es el resultado de la creciente conciencia de la importancia de la seguridad de código abierto, que trae más y más respaldo tecnológico y manos de trabajo para hurgar en el código de código abierto y corregir vulnerabilidades de manera rápida y eficiente".

En lugar de desconfiar El código abierto, la empresa ahora necesita aprender cómo apoyar los esfuerzos de la comunidad de código abierto, sugirió Arkins. Enterprise necesita aprovechar todo el arduo trabajo de la comunidad para informar vulnerabilidades de código abierto para garantizar que los componentes de código abierto que están utilizando estén actualizados y sean seguros.

Predicciones para 2020

Con el aumento continuo tanto del uso de código abierto como de la investigación de seguridad, la cantidad de vulnerabilidades de código abierto reportadas seguirá aumentando, según predice el informe de vulnerabilidad de 2019. La comunidad de código abierto está buscando formas de abordar el problema caos en el proceso de seguridad de código abierto con nuevas iniciativas.

Un buen ejemplo es el laboratorio de seguridad de GitHub. Facilita a los investigadores, mantenedores y usuarios informar vulnerabilidades de código abierto, y publica una solución verificada en una ubicación centralizada, señaló Arkin.

El proceso de divulgación incrustado de GitHub alentará a los proyectos de código abierto a informar vulnerabilidades correctamente, en lugar de solo empujar una solución.

Hacer que los propios mantenedores denuncien vulnerabilidades debería conducir a metadatos de mayor calidad. Los investigadores anotaron que eso mejoraría el proceso de presentación de informes para problemas como las versiones afectadas y las versiones fijas, a diferencia de los informes de terceros sobre el problema.

Años transformativos

Sin embargo, las predicciones optimistas del informe actual de WhiteSource pueden no ser ciertas, sugirió Thomas Hatch, CTO de SaltStack ya que el software de código abierto ha sufrido una transformación en los últimos años. [19659003] "La naturaleza de OSS ha cambiado, y el estado actual del software OSS es posiblemente peor que en el pasado", dijo a LinuxInsider. "Pero en lugar de considerar a OSS como bueno o malo, debemos tener en cuenta que la forma en que abordamos estas oportunidades cambia la naturaleza de cómo funcionan".

Originalmente, ingenieros dedicados con celo religioso hicieron software de código abierto. Trabajaron para crear el software más limpio posible, con el objetivo de dominar el mundo con código abierto, sugirió Hatch.

"Con el tiempo, esto cambió para convertirse en un brazo de desarrollo corporativo a medida que las corporaciones comenzaron a comprender cómo OSS podría aumentar y acelerar sus esfuerzos. Hoy en día existe una mentalidad emergente que prioriza el software freemium y prototipo que causa problemas en código abierto ", dijo.

El estado actual de seguridad en OSS no es sorprendente dado que esta actitud se combina con la facilidad de contribución, una cultura de solicitudes de extracción constante y presión sobre los desarrolladores para que presionen el botón de fusión, dijo Hatch.

"A medida que el código abierto continúa cambiando al ámbito del software prototipo, estos problemas seguirán aumentando. Tenga en cuenta que nuestra aceptación del software corporativo slapdash también está en aumento. Creo que los problemas de seguridad continuarán creciendo en todos los ámbitos ", agregó.

Lenguajes de programación más seguros

El informe WhiteSource compara cómo los siete principales lenguajes de codificación se comparan con las vulnerabilidades de código abierto reportadas en 2019 en años anteriores.

  • C todavía tiene el mayor porcentaje de vulnerabilidades debido al alto volumen de código escrito en este lenguaje. Pero esos números están disminuyendo a medida que otros lenguajes se vuelven más populares.
  • El número relativo de vulnerabilidades de PHP ha aumentado significativamente sin ninguna indicación del mismo aumento en popularidad.
  • Python todavía tiene un porcentaje relativamente bajo de vulnerabilidades. Su popularidad en la comunidad de código abierto continúa aumentando. Esto podría ser el resultado de prácticas de codificación seguras y no una investigación de seguridad laxa para proyectos de Python.

Estos son los CWE más comunes por año desde 2014 hasta 2019 para los siete lenguajes de programación más populares.

 CWE comunes por lenguaje de programación

Vulnerabilidades más comunes

Los cinco CWE principales en 2019 han sido consistentes en los últimos años. Todos están relacionados con la divulgación de información. Una gran preocupación es que los CWE más comunes se deben a errores simples y codificación imprecisa. Todos los desarrolladores podrían evitar este problema si se apegan a estándares de codificación bastante básicos.

Este gráfico muestra los cinco principales CWE.

 CWE más comunes en 2019

CWE-352, falsificación de solicitudes entre sitios (CSRF), ha emergido entre los 10 mejores CWE este año. CWE-89, SQL Injection, resurgió después de no aparecer como uno de los principales CWE desde 2015.

Esto podría haber resultado de un aumento en el volumen de proyectos web de código abierto desarrollados. Podría indicar que las vulnerabilidades web están en aumento. De cualquier manera, los redactores de códigos deben tener en cuenta, sugiere el informe.

Aquí están los CWE más comunes por año entre 2014 y 2019.

 CWE más comunes por año, 2014-2019

¿Es la puntuación de gravedad en la falla?

El informe aborda la fiabilidad de la puntuación CVSS (Sistema de puntuación de vulnerabilidad común), considerando si la mecánica de puntuación puede haber creado una anomalía estadística.

Los equipos de desarrollo deben priorizar rápidamente las alertas de seguridad. El puntaje CVSS suele ser el parámetro de referencia para la priorización de remediación. Según el informe, eso puede haber causado el aumento estadísticamente grande en el número de vulnerabilidades de código abierto reportadas el año pasado.

CVSS se ha actualizado varias veces en los últimos años (v2 a v3, y más recientemente v3.1) En los intentos de lograr un estándar medible y objetivo que ayude a apoyar a todas las organizaciones e industrias, señala el informe. Eso provocó un cambio en la definición de "vulnerabilidad de alta gravedad".

El cambio más notable en la actualización de v2 a v3 fue que los puntajes aumentaron sustancialmente. Una vulnerabilidad que hubiera sido clasificada 7.6 bajo CVSS v2 podría tener una calificación de 9.8 bajo CVSS v3.0. Con CVSS v3.0, los equipos enfrentaron un mayor número de vulnerabilidades de gravedad alta y crítica.

"Aún faltan las herramientas para priorizarlas y abordarlas, o incluso comprender completamente el impacto de las vulnerabilidades en su proyecto", indica el informe.

El equipo de investigación descubrió una disparidad en la distribución de severidad con el nuevo puntaje CVSS v3.1: el 17 por ciento de las vulnerabilidades eran críticas y solo el 2 por ciento era bajo. Esa no es una distribución normal.

¿Cómo pueden los equipos priorizar las vulnerabilidades de manera eficiente cuando más del 55 por ciento son de gravedad alta o críticas? el informe pregunta.

 Desglose de gravedad de CVSS

La ​​búsqueda de claridad

El cambio en las clasificaciones es solo una de las varias razones del reciente aumento en el número de puntajes de CVSS de gravedad alta y crítica, observó Whitekin de Arkin. El mayor enfoque en los temas críticos y altos es otra razón.

También lo es el hecho de que crear un CVE es un proceso lento que algunos prefieren evitar cuando se trata de problemas de menor gravedad. Eso explica el desequilibrio entre la cantidad de problemas de baja gravedad y de gravedad alta a crítica que se publican, dijo.

El ecosistema de seguridad continúa evolucionando. La comunidad de investigación de seguridad está trabajando para encontrar un estándar objetivo de puntaje de severidad que ayude a los usuarios de todos los sectores verticales e industrias a enfrentar nuevos desafíos. Los estándares aún se están perfeccionando, señaló Arkin.

"Eso no significa que los puntajes de gravedad no sean confiables. Es importante recordar que el último CVSS v3.1 mide la gravedad y no los riesgos", explicó. 19659003] Las organizaciones deben considerar el impacto de una vulnerabilidad específica en la seguridad de sus productos en función de una serie de factores. El proceso involucra más que el puntaje de severidad, agregó Arkin.

Lo que se necesita

Los CWE más comunes en los últimos años, en la mayoría de los principales lenguajes de programación, resultaron de errores de codificación bastante simples, según Arkin. Por lo tanto, los equipos de desarrollo deben hacer que la codificación segura sea una prioridad. Eso incluye capacitación, así como el uso de herramientas y procesos automatizados para detectar posibles fallas lo antes posible en el proceso de desarrollo.

Los desarrolladores, DevOps y los equipos de seguridad enfrentan el desafío de abordar largas listas de alertas de seguridad. Los datos y las ideas en el informe WhiteSource pueden ayudarlos a comprender mejor cómo abordar las vulnerabilidades de seguridad de código abierto de manera eficiente.

"La mayor conciencia de que vemos en torno a la seguridad de código abierto significa que la gran tecnología, junto con la comunidad de código abierto, ha sido invertir mucho en seguridad de código abierto ", dijo, y agregó que la inversión continua garantizará que los usuarios de código abierto se mantengan informados sobre las vulnerabilidades.

Mirando hacia adelante

Estos problemas ocurren en prácticamente todos nuestros proyectos de software de código abierto favoritos, según el informe. La conclusión más importante es que el hecho de que los proyectos de código abierto populares tengan vulnerabilidades no significa que sean inherentemente inseguros.

En cambio, significa que los usuarios de código abierto deben ser conscientes de los riesgos de seguridad. Eso incluye asegurarse de que mantengan las dependencias actualizadas.

"El panorama de vulnerabilidades de código abierto puede parecer complejo y desafiante al principio. Pero hay formas de ganar visibilidad y control sobre los componentes de código abierto que componen los productos que lanzamos ", concluye el informe.

Un proyecto de código abierto con vulnerabilidades no es inherentemente inseguro, enfatizó Arkin. Por el contrario, probablemente significa que hay muchas manos trabajando para garantizar que esté libre de vulnerabilidades. También significa que los encargados del mantenimiento se aseguran de que los usuarios tengan toda la información que necesitan.


Leave a Reply

Your email address will not be published. Required fields are marked *