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: tienden a dar muchas falsas alarmas, lo que cansa a los desarrolladores a la hora de prestarles atención. Esto hace que los desarrolladores pierdan tiempo y confianza en las herramientas. Para trabajar de forma eficiente y eficaz en ciberseguridad, se necesita un buen filtro que evite esos falsos positivos. Eso es precisamente lo que hace AutoTriage con SAST .

Ejemplo de verdadero positivo

El siguiente es un ejemplo de un SAST . SAST de 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 poderoso para señalar muchos tipos diferentes de vulnerabilidades.

En este ejemplo, vemos que AutoTriage marca una muestra como «prioridad muy alta para corregir». El SAST apunta a una posible vulnerabilidad NoSQL. El código representa un punto final de inicio de sesión donde los usuarios pueden proporcionar un nombre y una contraseña. Hay una llamada a la base de datos para buscar un registro que coincida tanto con el nombre como con 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 SAST fue un verdadero positivo. 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 SAST promedio SAST .

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 SAST es la cantidad de falsas alarmas que producen. A continuación se muestra un ejemplo de ello. Existe una posible inyección SQL en la que se inyecta un «productName» en una consulta SQL. Además, este «productName» proviene del cuerpo de la solicitud, por lo que está controlado por el usuario. Afortunadamente, hay una lista de permitidos que comprueba si productName es «iPhone15», «Galaxy S24», «MacBook Pro» o «ThinkPad X1». Esto garantiza que productName no pueda contener una carga útil de ataque como productName = «iPhone15'; DROP TABLE products; - - ».

Una lista de permitidos como la que se muestra 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 de permitidos.

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 AppSec , suelen comparar las diferentes soluciones disponibles en el mercado. Una forma habitual en que las empresas con menos experiencia comparan a los proveedores es contando el número de vulnerabilidades encontradas en su código fuente. No es de extrañar que tiendan a creer que un mayor número de vulnerabilidades equivale a mejores herramientas. A veces eligen a su proveedor basándose en esta evaluación errónea. En consecuencia, algunas AppSec se muestran reacias a filtrar los falsos positivos, ya que obtendrían peores resultados en esta comparación tan habitual.

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

Hemos habilitado esta función para 91 SAST en diferentes lenguajes, incluidos 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

Hemos lanzado una potente función para filtrar los falsos positivos en SAST y ayudar a priorizar las muestras verdaderas positivas. Está disponible para que todo el mundo la pruebe, incluso para las cuentas gratuitas. Esta función supone un gran avance en la reducción del efecto «criar al lobo» en la ciberseguridad, ya que ayuda a los desarrolladores a centrarse en lo que realmente importa: resolver vulnerabilidades reales y dedicar más tiempo a crear funciones para sus clientes.