[27/06/2022] El software de código abierto (OSS) se ha convertido en un pilar de la mayoría de las aplicaciones, pero también ha creado retos de seguridad para los desarrolladores y los equipos de seguridad, retos que pueden ser superados por el creciente movimiento de "cambio a la izquierda", según dos estudios publicados esta semana.
Más de cuatro de cada cinco organizaciones (41%) no confían mucho en su seguridad de código abierto, según revelan los investigadores de Snyk, una empresa de seguridad para desarrolladores, y la Fundación Linux en su informe The State of Open Source Security.
También señala que el tiempo para corregir las vulnerabilidades en los proyectos de código abierto ha aumentado constantemente en los últimos tres años, más del doble de 49 días en el 2018 a 110 días en el 2021.
El debate del código abierto: Productividad frente a seguridad
El informe, basado en la encuesta de más de 550 encuestados, también señala que el proyecto medio de desarrollo de aplicaciones tiene 49 vulnerabilidades y 80 dependencias directas en las que un proyecto llama al código de fuente abierta. Además, el informe revela que menos de la mitad de las organizaciones (49%) tienen una política de seguridad para el desarrollo o el uso de OSS. Esa cifra es peor en el caso de las empresas medianas y grandes: el 27%.
"Los desarrolladores de software tienen hoy sus propias cadenas de suministro", explica en un comunicado el director de relaciones con los desarrolladores de Snyk, Matt Jarvis. "En lugar de ensamblar piezas de automóviles, están ensamblando código parcheando componentes de código abierto existentes con su código único. Aunque esto conduce a una mayor productividad e innovación, también ha creado importantes problemas de seguridad".
El desplazamiento de la seguridad hacia la izquierda revela antes las vulnerabilidades
Otra encuesta -el informe AppSec Shift Left Progress Report- sugiere que se puede conseguir una mejor seguridad del OSS si se desplaza la seguridad "hacia la izquierda" o más cerca del comienzo del ciclo de vida del desarrollo del software. El informe, basado en la experiencia de los usuarios del producto Core de ShiftLeft, descubrió que el 76% de las nuevas vulnerabilidades se solucionaban en dos sprints.
Una de las razones por las que las vulnerabilidades se solucionan tan rápido es porque se encuentran rápidamente. "Cada cambio en el código que realiza un desarrollador se escanea en una media de 90 segundos", afirma el director general y cofundador de ShiftLeft, Manish Gupta. "Como el código está todavía fresco en la mente del desarrollador, le resulta más fácil corregir la vulnerabilidad".
El informe reconoce que las mejoras en su software no fueron la única razón de la mejora en los tiempos de escaneo. "Hemos visto que el tamaño medio de las aplicaciones en términos de líneas de código ha disminuido", señala. "Esto se alinea con más organizaciones que se mueven a microservicios y aplicaciones más pequeñas y modulares".
Aumento del escaneo de vulnerabilidades
Los clientes de ShiftLeft también vieron un descenso en el número de vulnerabilidades OSS que necesitaban abordar en sus aplicaciones en un 97%, ya que los adversarios solo podían explotar el 3% de esas vulnerabilidades. Cuando se analizan las vulnerabilidades del OSS, señaló Gupta, no se trata de cuántas vulnerabilidades tiene una aplicación, sino de dónde pueden ser explotadas por un malhechor.
ShiftLeft también informó que sus clientes mejoraron el tiempo medio necesario para mitigar las vulnerabilidades en un 37%, pasando de 19 días en el 2021 a 12 días en el 2022. Atribuyó este descenso a que los desarrolladores y los equipos de seguridad realizan más escaneos en las primeras fases del proceso de desarrollo. "Algunos de nuestros clientes están haciendo hasta 30 mil escaneos al mes", anotó Gupta.
¿Es realmente posible explotar la vulnerabilidad?
El informe plantea la pregunta: "¿Es la vulnerabilidad realmente alcanzable por un atacante?". Esto es importante a la hora de abordar fallas de día cero como Log4J, al que algunas organizaciones todavía se enfrentan meses después de su descubrimiento en diciembre del 2021. Dice que el 96% de Log4J en uso en las aplicaciones de sus clientes no estaba en riesgo de ataque.
Remediar las vulnerabilidades que no son explotables tendrá un impacto nulo en el riesgo. Despriorícela y céntrese en otras.
Basado en el artículo de John P. Mello Jr (CSO) y editado por CIO Perú