Evaluating Cryptographic API Misuse Detectors for Go
Este artículo presenta el primer estudio exhaustivo del mal uso de las API criptográficas en Go mediante el establecimiento de una taxonomía de 14 clases de mal uso, la evaluación de cuatro herramientas de detección en 328 proyectos y la identificación de 7.473 vulnerabilidades para destacar brechas significativas en la cobertura de detección actual.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que estás construyendo una fortaleza. Tienes las cerraduras más seguras y mejores del mundo (APIs criptográficas) para proteger tu tesoro. Pero, si instalas la cerradura al revés, usas una llave frágil o olvidas asegurar la puerta, tu fortaleza es tan vulnerable como si no tuvieras cerradura alguna. Esto es lo que sucede cuando los desarrolladores "malutilizan" herramientas criptográficas: creen que están seguros porque usaron la tecnología correcta, pero cometieron un error en cómo la utilizaron.
Este trabajo es como una inspección de control de calidad para un tipo específico de material de construcción: el lenguaje de programación Go. Go es el lenguaje utilizado para construir algunas de las infraestructuras más críticas de internet (como los sistemas que gestionan el tráfico de internet o los centros de datos seguros). Mientras que los expertos han estudiado estos "errores de instalación de cerraduras" en otros lenguajes (como Java) durante años, nadie había revisado realmente los sitios de construcción de Go hasta ahora.
Aquí está lo que hicieron los investigadores, explicado de forma sencilla:
1. Los inspectores (Las herramientas)
Los investigadores reunieron cuatro "inspectores de seguridad" diferentes (herramientas de software) para escanear el código Go en busca de estos errores:
- CodeQL: Un inspector poderoso, de estilo académico, que examina cómo fluyen los datos a través del código.
- Gopher: Una herramienta especializada construida específicamente para Go, conocida por ser muy agresiva al encontrar problemas potenciales.
- Gosec: Una herramienta popular, construida por la comunidad, que verifica errores de seguridad comunes.
- Snyk Code: Una herramienta comercial que utiliza inteligencia artificial y análisis estático para encontrar errores.
2. El plano (La taxonomía)
Antes de comenzar a escanear, los investigadores crearon una lista maestra de verificación de 14 formas diferentes en que un desarrollador puede equivocarse con la criptografía. Piensa en esto como una lista de errores comunes, tales como:
- Usar una cerradura demasiado antigua y débil (Algoritmos inseguros).
- Usar una llave demasiado corta o fácil de adivinar (Longitud de clave corta).
- Olvidar verificar si la persona en la puerta es realmente quien dice ser (Sin validación de clave de host).
- Usar un patrón predecible para el mecanismo de la cerradura (Vectores de inicialización predecibles).
3. La inspección (El experimento)
Tomaron 328 proyectos reales y populares de Go (como el software que ejecuta Kubernetes o Terraform) y ejecutaron los cuatro inspectores sobre ellos.
- El resultado: Los inspectores encontraron un total de 7,473 errores.
- La sorpresa: Los inspectores no estuvieron de acuerdo entre sí en absoluto.
- Gosec fue el más activo, encontrando la mayor cantidad de errores, pero también marcó muchas cosas que no eran realmente peligrosas (como encontrar una "cerradura débil" en un archivo de código de muestra que nadie usaría en la vida real).
- Gopher encontró un conjunto único de errores que los demás pasaron por alto, pero a veces se quedaba atascado o fallaba al ejecutarse en ciertos proyectos.
- Snyk Code fue muy rápido y preciso, encontrando menos errores pero estando muy seguro de los que sí encontró.
- CodeQL fue el más lento (tarda mucho tiempo en configurar su "base de datos" del código) pero encontró errores muy específicos y complejos que los demás pasaron por alto.
4. El veredicto
La conclusión principal es que ningún inspector individual es perfecto.
- Si solo usas una herramienta, podrías pasar por alto un agujero enorme en tu pared porque esa herramienta no sabía cómo buscarlo.
- Si usas todas ellas, obtienes muchas "falsas alarmas" (advertencias sobre cosas que en realidad no están rotas), lo cual puede ser abrumador.
Los investigadores descubrieron que las herramientas a menudo no estaban de acuerdo sobre si un fragmento específico de código era realmente un error. Por ejemplo, una herramienta podría decir: "¡Esta clave es demasiado corta!", mientras que otra dice: "Eso está bien".
La conclusión
Este estudio es la primera vez que alguien verifica sistemáticamente qué tan bien podemos encontrar estos errores de seguridad específicos en el código Go. Descubrieron que, aunque tenemos herramientas para ayudar, actualmente son como un grupo de inspectores que hablan idiomas diferentes y tienen definiciones distintas de cómo se ve una "cerradura rota".
Para mantener seguros los sistemas basados en Go, los ingenieros de seguridad no deberían confiar en una sola herramienta. En su lugar, deberían usar una combinación de estas herramientas (un "conjunto") para cubrir la red más amplia de errores, mientras entienden que necesitarán revisar manualmente los resultados para separar los peligros reales de las falsas alarmas.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.