Cómo corregir medio millón de vulnerabilidades de seguridad

Los hackatones son muy conocidos entre los equipos de desarrollo de software por impulsar la innovación y la colaboración. Entonces, ¿qué pasaría si aplicáramos ese modelo a la ciberseguridad para mejorar la postura de seguridad de las aplicaciones de una organización? Sería un sueño hecho realidad para cualquier CISO y profesional de seguridad, y eso es precisamente lo que nos propusimos hacer en Snyk en febrero de 2023.

Mira algunos de los momentos más divertidos de nuestros paneles.

Nos propusimos corregir 200,000 vulnerabilidades de seguridad. Así fue como terminó todo.

Organizar una jornada de corrección de vulnerabilidades

La clave para organizar un evento exitoso es asegurarse de que los desarrolladores y profesionales de seguridad se diviertan mientras aprenden nuevas habilidades que puedan aplicar en sus proyectos personales o profesionales. Con ese objetivo, establecimos lo siguiente:

1. Con apoyo continuo, invitamos a los participantes del hackatón a unirse a sus colegas en la comunidad de Discord de Snyk para recibir lecciones de seguridad y ayuda con las correcciones.

2. Una transmisión en vivo de 24 horas que cumplió nuestra promesa de fomentar la educación fue un evento clave de The Big Fix de este año. Organizamos la transmisión en vivo de 24 horas a nivel mundial en YouTube y Twitch, con ponentes de Atlassian, Dynatrace, Morgan Stanley, The Linux Foundation, Sysdig, AWS, StackHawk y otras organizaciones.

3. Premios: Queríamos reconocer el esfuerzo de cada participante por crear software más seguro. Por eso, todas las personas que corrigieron al menos una vulnerabilidad de seguridad recibieron una camiseta de edición limitada de The Big Fix o un crédito de $15 de OpenCollective que pueden usar para donar a proyectos de código abierto y a sus mantenedores.

4. Tabla de posiciones: Para darle un toque competitivo, presentamos una tabla con quienes más vulnerabilidades corrigieron. Los tres participantes que corrigieron más vulnerabilidades de seguridad recibieron, respectivamente, un visor de realidad virtual (primer lugar), una bocina inalámbrica (segundo lugar) y un kit de inicio Arduino (tercer lugar).

Una de las grandes ventajas del hackatón es que no necesitabas experiencia previa en seguridad de aplicaciones ni en seguridad en la nube para participar y subir en la tabla de posiciones.

Esto es posible gracias al enfoque de Snyk centrado primero en los desarrolladores, a sus amplias integraciones con el ecosistema y a sus capacidades de corrección automatizada, que te permiten encontrar y corregir problemas de seguridad fácilmente. Tanto si eres desarrollador, ingeniero de DevOps, profesional de seguridad o de control de calidad, Snyk tiene las herramientas que necesitas para empezar.

Hoy más que nunca, es una gran oportunidad para empezar con Snyk Code, Snyk Open Source, Snyk Container y Snyk Cloud.

Protejamos el software del mundo

Entonces, ¿cómo nos fue? Ahora que terminó The Big Fix, analicemos los datos y repasemos los resultados de organizar un evento que ayuda a los desarrolladores a corregir problemas de seguridad.

En un mes, los participantes de The Big Fix aportaron 597,589 correcciones de seguridad a sus proyectos de software, tanto privados como de código abierto. Más de 1800 usuarios se registraron para el evento. Entre los participantes hubo más de 120 empleados de Snyk, más de 220 clientes y más de 1,480 ingenieros de distintas empresas.

Analizamos en profundidad la base de datos de Snyk para determinar el impacto del evento en la seguridad de los proyectos supervisados con Snyk. Por eso, las siguientes métricas y observaciones incluyen todos los análisis de producto recopilados para cualquier actividad de cuenta registrada en el evento; abarcan más proyectos y vulnerabilidades de seguridad encontradas y corregidas que los que se agregaron al hackatón.

Las imágenes de contenedores son las más propensas a tener vulnerabilidades, pero también las más fáciles de corregir.

De los millones de vulnerabilidades de seguridad detectadas en proyectos de contenedores, código e infraestructura supervisados con Snyk, los clasificados como proyectos de contenedores Docker tuvieron una tasa de corrección del 73.3%. Es razonable afirmar que un factor importante de esta alta tasa es que Snyk Container ofrece correcciones automatizadas mediante pull request, con recomendaciones de imágenes base que sugieren de forma proactiva imágenes de contenedor alternativas con menos vulnerabilidades.

Las acciones de seguridad relacionadas con el código y las dependencias tienen una tasa insignificante de aplicación de correcciones. Snyk Code logró encontrar más de 82,160 posibles vulnerabilidades de seguridad en el código; los participantes corrigieron el 10.2%. Snyk Open Source, que detecta vulnerabilidades conocidas públicamente en dependencias de código abierto, tuvo una tasa de corrección del 14.4%. Como las correcciones de dependencias se automatizan mediante pull request y los problemas de seguridad del código se gestionan en el IDE con el motor de recomendaciones de Snyk, miles de vulnerabilidades de seguridad se mitigaron de forma temprana (y rápida) durante el proceso de desarrollo.

Veamos más de cerca el conjunto de datos de los proyectos de imágenes de contenedores. Los 10 principales proyectos de contenedores Docker supervisados por Snyk presentan una tasa increíblemente alta de corrección de problemas de seguridad, lo que respalda la afirmación anterior de que son mucho más fáciles y rápidos de corregir. Las distribuciones base de Ubuntu y las imágenes de contenedores, como ubuntu:rolling y las imágenes de node, presentan tasas de corrección de problemas de seguridad superiores al 90%.

Se corrige antes y más rápido entre el 13% y el 30% de las vulnerabilidades de seguridad conocidas públicamente

Al profundizar en los distintos ecosistemas de lenguajes, también podemos observar las tasas de corrección de seguridad aplicadas a cada lenguaje de programación. Estas cifras pueden estar sesgadas por vulnerabilidades detectadas en problemas de seguridad de baja importancia, como los reportados en dependencias de desarrollo. También puede haber problemas de seguridad imposibles de corregir porque el código de los proyectos ya no se mantiene. En general, las vulnerabilidades de seguridad relacionadas con dependencias tienen una tasa de corrección de alrededor del 13% al 30%; este proceso se puede automatizar para que los desarrolladores de software se concentren en crear aplicaciones, en lugar de resolver problemas de seguridad.

El código Go es propenso a errores de programación segura relacionados con denegación de servicio, flujo de control y manejo de punteros

Las principales vulnerabilidades corregidas en Go muestran que los desarrolladores dedican tiempo a mitigar errores de programación segura relacionados con el flujo de control del programa, la denegación de servicio y el manejo de punteros. Estas son las 5 principales vulnerabilidades de seguridad corregidas en proyectos Go:

• CWE-400: consumo de recursos no controlado

• CWE-266: asignación incorrecta de privilegios

• CWE-787: escritura fuera de los límites

• CWE-674: recursión no controlada

• CWE-476: desreferencia de puntero NULL

Los proyectos Python son más vulnerables a problemas de memoria, validación de entradas y flujo de control del programa

Los principales tipos de vulnerabilidades de Python tienen similitudes con los de los proyectos Go, como el consumo de recursos no controlado, la escritura fuera de los límites y la lectura fuera de los límites. Entre otras vulnerabilidades principales identificadas en bases de código Python se encuentran:

• CWE-369: división entre cero

• CWE-617: aserción alcanzable

• CWE-1333: complejidad ineficiente de expresiones regulares

Las bases de código Java y JavaScript comparten tipos de vulnerabilidades principales

Entre los 10 principales tipos de vulnerabilidades que supervisamos durante The Big Fix, identificamos un conjunto de CWE compartidas por las bases de código Java y JavaScript:

• CWE-400: consumo de recursos no controlado

• CWE-94: control inadecuado de la generación de código ('inyección de código')

• CWE-22: limitación inadecuada de una ruta de acceso a un directorio restringido ('recorrido de rutas')

• CWE-200: exposición de información confidencial a un actor no autorizado

Ruby es más vulnerable a la denegación de servicio, los ataques de secuencias de comandos entre sitios y el contrabando de solicitudes HTTP

Ruby, conocido principalmente por Ruby on Rails, se asocia sobre todo con el desarrollo web. Por eso, no sorprende que sus 5 principales vulnerabilidades de seguridad, que también se corrigieron durante el evento, impliquen riesgos para las aplicaciones web:

• CWE-1333: complejidad ineficiente de expresiones regulares

• CWE-400: consumo de recursos no controlado

• CWE-79: neutralización inadecuada de entradas durante la generación de páginas web ('secuencias de comandos entre sitios')

• CWE-444: interpretación inconsistente de solicitudes HTTP ('contrabando de solicitudes/respuestas HTTP')

• CWE-200: exposición de información confidencial a un actor no autorizado

De hecho, una de las principales vulnerabilidades que los participantes encontraron y corrigieron es un problema de seguridad poco conocido: el contrabando de solicitudes HTTP.

Las vulnerabilidades de seguridad más fáciles de corregir se detectaron mediante pruebas estáticas de aplicaciones

Las pruebas estáticas de aplicaciones son un enfoque que utiliza información del código y flujos de trabajo de rutas de código, como árboles de sintaxis abstracta, para identificar posibles vulnerabilidades y convenciones de programación inseguras. Son una excelente manera de ofrecer comentarios tempranos a los desarrolladores y señalar problemas de seguridad mientras escriben el código, en lugar de hacerlo más adelante, cuando las funciones ya están implementadas.

Snyk Code ofrece información de seguridad integrada en el IDE y recomendaciones de corrección que los desarrolladores pueden aplicar fácilmente al instalar la extensión de VS Code (también se admiten IntelliJ y otros IDE). Brian Clark y Nate Michalov muestran cómo encontrar y corregir problemas de seguridad en esta sesión de programación en vivo:

Play Video: How to Get Started with Snyk Code (feat. Nate Michalov) - The Big Fix 2022 by Snyk

De todos los problemas detectados por la herramienta SAST de Snyk Code, los siguientes tipos de vulnerabilidades fueron los más comunes:

• ​​CWE-94: control inadecuado de la generación de código ('inyección de código')

• CWE-79: neutralización inadecuada de entradas durante la generación de páginas web ('secuencias de comandos entre sitios')

• CWE-916: uso de un hash de contraseña con un esfuerzo computacional insuficiente

• CWE-798: uso de credenciales codificadas de forma fija

• CWE-352: falsificación de solicitudes entre sitios (CSRF)

¿Qué sigue?

Queremos agradecer a todas las personas que participaron en The Big Fix este año y aprovechar la oportunidad para invitarte a uno de nuestros próximos eventos públicos, donde podrás aprender más sobre seguridad de aplicaciones y conocer a otras personas del ámbito de la ciberseguridad:

• Taller CTF 101 (25 de mayo de 2023): un taller práctico que te enseña a resolver desafíos de captura la bandera.

• Taller de hacking ético (21 de junio de 2023): un taller práctico que te enseña a realizar hacking ético y divulgación responsable.

• DevSecCon (27 de junio de 2023): nuestra conferencia insignia de la comunidad sobre todo lo relacionado con DevSecOps.

Por último, si te interesa conectar con desarrolladores y profesionales de seguridad que comparten tus intereses, únete al Discord de DevSecOps.