Falsas alarmas en ciberseguridad

La fábula del pastorcillo mentiroso cuenta la historia de un joven pastor que se burlaba de los demás aldeanos diciéndoles que un lobo atacaba el rebaño. Los aldeanos le creyeron al principio, pero él solo se reía de ellos. Cuando el pastorcillo repitió su broma, los aldeanos empezaron a ignorarle y, en cierto momento, un lobo de verdad llegó y atacó a las ovejas. El pastorcillo "gritó lobo", pero ya nadie le creyó.

Las herramientas de ciberseguridad han actuado como pastores: suelen dar muchas falsas alarmas, lo que fatiga a los desarrolladores para que les presten atención. Esto hace que los desarrolladores pierdan tiempo y confianza en las herramientas. Para trabajar de manera eficiente y efectiva en ciberseguridad, se necesita un buen filtro para evitar esos falsos positivos. Eso es exactamente lo que hace AutoTriage para las vulnerabilidades SAST.

Ejemplo de verdadero positivo

A continuación, se muestra un ejemplo de un hallazgo SAST. SAST significa Pruebas de seguridad de aplicaciones estáticas, que se traduce libremente como: detectar patrones peligrosos en el código fuente, sin ejecutar el código. Es un método potente para señalar muchos tipos diferentes de vulnerabilidades.

En este ejemplo, vemos a AutoTriage marcando una muestra como «prioridad muy alta de corrección». El hallazgo SAST apunta a una posible vulnerabilidad NoSQL. El código representa un punto de conexión de inicio de sesión donde los usuarios pueden proporcionar un nombre de usuario y una contraseña. Hay una llamada a la base de datos para buscar un registro coincidente tanto para el nombre de usuario como para la contraseña.

The problem here is that NoSQL allows you to insert objects like { $ne: undefined }. In that case, the match will be based on anything that is different from undefined. Imagine that an attacker would upload something like this:

{
	name: LeoIVX,  
    password: { $ne: undefined }
}

En ese caso, el atacante podría iniciar sesión como el papa (si el papa tuviera una cuenta con ese nombre de usuario en esa plataforma de software), ya que la contraseña siempre coincidiría con la consulta.

En este caso, el hallazgo SAST fue un verdadero positivo real. AutoTriage hace más que solo confirmar aquí: también aumenta la prioridad, ya que esta vulnerabilidad es más fácil de explotar y tiene una gravedad mayor que el hallazgo SAST promedio.

Cuando se informa de un problema como este, debe solucionarse lo antes posible. No hay método más rápido que usar la herramienta AutoFix de Aikido. Esto creará una pull request (o merge request) con un solo clic. En este caso, el resultado es:

AutoFix siempre sugerirá la solución más sencilla que resuelva adecuadamente la vulnerabilidad. En este caso, basta con convertir tanto el nombre como la contraseña para asegurar el endpoint y alinearse con la intención del desarrollador.

Tenga en cuenta que las contraseñas nunca deben compararse directamente y, en su lugar, deben utilizarse hashes de contraseñas; este ejemplo se usó por simplicidad. El LLM utilizado por AutoFix tiene instrucciones explícitas de no corregir ningún otro problema que no sea la vulnerabilidad reportada, por lo que las pull requests alcanzan la mejor práctica de resolver un problema a la vez.

Ejemplo de falso positivo

Como se mencionó anteriormente, el verdadero problema de las herramientas SAST es la cantidad de falsas alarmas que producen. Un ejemplo de esto se puede encontrar a continuación. Existe una posible inyección SQL donde un «productName» se inyecta en una consulta SQL. Además, este «productName» proviene del cuerpo de la solicitud, por lo que está controlado por el usuario. Afortunadamente, existe una lista blanca que verifica si productName es «iPhone15», «Galaxy S24», «MacBook Pro» o «ThinkPad X1». Esto garantiza que productName no puede contener una carga útil de ataque como productName = «iPhone15»; DROP TABLE products; - - ».

Una lista blanca como la que se presenta en este ejemplo es una contramedida eficaz contra la inyección SQL. Pero los escáneres heredados como Semgrep no logran evaluar la eficacia de dichas listas blancas.

Los Grandes Modelos de Lenguaje (LLM) ofrecen una gran oportunidad aquí: pueden comprender mucho más contexto del código fuente y filtrar muestras como esta.

La narrativa de seguridad "Sin chorradas" de Aikido

Cuando las empresas de software buscan proveedores de AppSec, a menudo comparan diferentes soluciones disponibles en el mercado. Una forma típica en que las empresas menos experimentadas comparan proveedores es contando el número de vulnerabilidades encontradas en su código fuente. No será una sorpresa que tiendan a creer que más vulnerabilidades equivalen a mejores herramientas. A veces eligen a su proveedor basándose en esta mala evaluación. En consecuencia, algunas empresas de AppSec dudan en filtrar los falsos positivos, ya que tendrían un rendimiento inferior en esta comparación frecuente.

En Aikido, adoptamos un enfoque diferente. Nuestra narrativa "Sin tonterías" significa que queremos ayudar a los clientes tanto como sea posible, incluso si esto implica algunas ofertas perdidas a corto plazo. AI AutoTriage es un claro ejemplo de esto, ya que esta característica diferencia la oferta de Aikido de otras en el mercado.

Disponibilidad

Habilitamos esta funcionalidad para 91 reglas SAST en diferentes lenguajes, incluyendo JavaScript/TypeScript, Python, Java, .NET y PHP. Se están añadiendo más reglas a un ritmo rápido.

Esta característica está habilitada para todos, incluidas las cuentas gratuitas. Dicho esto, las cuentas gratuitas pueden alcanzar el número máximo de llamadas a LLM con bastante facilidad.

Gating de CI

El gating de CI es el proceso por el cual Aikido escanea en busca de vulnerabilidades en cada pull request. AI AutoTriage también está ahora habilitado para esta funcionalidad, lo que simplifica considerablemente el flujo de trabajo.

Imagina que introdujiste una vulnerabilidad de path traversal en una pull request y aplicaste un AutoFix. Esa corrección normalmente usaría una denylist de patrones antes de leer o escribir el archivo. Dado que las denylists son difíciles de interpretar con patrones codificados, incluso la versión corregida seguiría siendo marcada como un problema. Esto ahora está resuelto gracias a la aplicación de nuestro AutoTriage directamente en el pipeline de CI.

Conclusión

Lanzamos una potente funcionalidad para filtrar los hallazgos SAST de falsos positivos y también para ayudar con la priorización de las muestras de verdaderos positivos. Está disponible para que todos la prueben, incluso para cuentas gratuitas. Esta funcionalidad es un gran paso adelante en la reducción del efecto «El pastor mentiroso» en ciberseguridad, ayudando a los desarrolladores a centrarse en lo que realmente importa: resolver vulnerabilidades reales y tener más tiempo para desarrollar funcionalidades para sus clientes.