Desarrollo seguro: Parte 3 — SAST: análisis estático de código

Un desarrollador experimentado encuentra vulnerabilidades en el código ajeno por signos conocidos: los datos del usuario terminan directamente en una consulta SQL, la contraseña se compara con ==, la ruta al archivo se arma a partir de un parámetro de la petición. Pero nadie puede revisar cien mil líneas y no pasar nada por alto. Ese trabajo lo asume SAST.

Qué es SAST

SAST (Static Application Security Testing, análisis estático de seguridad de aplicaciones) — comprobación del código fuente sin ejecutar la aplicación. El analizador descompone el código en un árbol sintáctico y busca en él construcciones peligrosas.

La técnica principal es el análisis del flujo de datos (taint analysis). El analizador marca las “fuentes”: lugares de los que provienen datos no confiables: parámetros de la petición, cabeceras, cuerpo del formulario. Luego rastrea si esos datos llegarán al “sink” — una función peligrosa como ejecución de SQL, lanzamiento de un comando de shell o escritura en HTML — sin pasar por alguna limpieza o escape. Si llegan, aparece una advertencia.

Las pruebas no sustituyen ese trabajo. Una prueba verifica que al introducir el nombre Ivan en la base se grabe Ivan. SAST verifica qué pasará si en lugar del nombre llega ' OR 1=1 --, aunque funcionalmente el código funcione correctamente.

Ejemplo: inyección SQL

@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    # peligroso: el valor de la petición se inserta en el texto de la consulta
    query = "SELECT * FROM users WHERE id = %s" % user_id
    db.execute(query)

La regla del analizador describe exactamente esta situación: el valor de request mediante format de cadenas llega a execute(). La corrección es una consulta parametrizada: db.execute("SELECT * FROM users WHERE id = %s", (user_id,)). El driver de la base envía el valor por separado del texto de la consulta, y la inyección se vuelve imposible.

Herramientas

Semgrep

Semgrep — el analizador ligero más difundido. Las reglas se escriben en YAML casi en el propio lenguaje del código, por lo que una regla propia para el proyecto se puede crear en unos minutos.

Es importante entender cómo está su licencia. El motor Semgrep Community Edition se distribuye bajo LGPL-2.1 y es gratuito. Pero sus capacidades están limitadas: según la documentación de Semgrep, la versión abierta analiza las interacciones solo dentro de una función. El análisis entre funciones y entre archivos está en el producto de pago Semgrep Code. Las reglas que mantiene la propia compañía se distribuyen bajo su propia licencia: se pueden usar para tareas internas, pero no se pueden integrar en productos y servicios competidores.

Opengrep

Cuando Semgrep trasladó parte de las capacidades a la licencia comercial, un grupo de empresas creó un fork: Opengrep. Se distribuye bajo LGPL-2.1, es compatible con las reglas de Semgrep y desarrolla el análisis del flujo de datos en abierto. Si te importa que la herramienta permanezca completamente abierta, Opengrep es el reemplazo natural.

SonarQube Community Build

SonarQube — plataforma que combina la búsqueda de vulnerabilidades con la comprobación de la calidad del código: duplicaciones, complejidad, cobertura de pruebas. La edición gratuita Community Build se distribuye bajo LGPL-3.0 y se instala en un servidor propio. Para un equipo pequeño es una opción cómoda si se necesita un informe general del proyecto y no solo un escáner en CI.

CodeQL

CodeQL de GitHub describe el código como una base de datos sobre la que se escriben consultas. Es uno de los analizadores más profundos. Para repositorios públicos en GitHub el escaneo de código está incluido gratuitamente. Para repositorios privados se necesita el producto de pago GitHub Code Security, y su disponibilidad y pago para una empresa rusa hay que comprobarlo por separado.

Cómo ejecutar localmente

Semgrep se instala vía pip o Homebrew:

pip install semgrep
semgrep scan --config p/python

p/python — conjunto de reglas listo para Python del registro de Semgrep. Para JavaScript existe p/javascript, para comprobaciones generales — p/default. Opengrep se instala con un script desde el repositorio del proyecto y acepta las mismas reglas.

SAST en CI

Tiene sentido ejecutar la comprobación en cada pull request: una vulnerabilidad encontrada antes de hacer el merge sale lo más barato. Ejemplo de job para GitHub Actions sobre la imagen oficial de Semgrep:

name: sast
on: [pull_request]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep scan --config p/python --error

La clave --error termina el comando con error si se encuentran problemas, y el CI no permite mergear el código. El antiguo wrapper semgrep-action está declarado obsoleto, por eso Semgrep se ejecuta directamente, como en el ejemplo. En GitLab CI se hace lo mismo con un job usando la misma imagen.

Para no ahogarte en hallazgos antiguos, empieza en un modo que compruebe solo el código cambiado, o primero genera un informe base y acordad que las nuevas advertencias están prohibidas, y las antiguas se resuelven gradualmente.

Falsos positivos

Ningún analizador es perfecto: a veces código seguro se marca como peligroso.

• Ajuste de reglas. Una regla demasiado estricta se puede desactivar o afinar para el proyecto.
• Supresión in situ. El comentario # nosemgrep encima de la línea desactiva la comprobación para ella. Conviene explicar al lado por qué el código es seguro, de lo contrario dentro de seis meses nadie lo recordará.
• Clasificación. En el equipo alguien se encarga de los informes y etiqueta los hallazgos como “arreglar” o “falso positivo”.

Si las supresiones se vuelven muchas, es una señal para revisar el conjunto de reglas, no para acostumbrarse al ruido.

Por dónde empezar

1. Ejecuta Semgrep u Opengrep en tu proyecto una vez y analiza los hallazgos de nivel ERROR.
2. Añade la comprobación en CI en los pull requests, al principio solo para las advertencias nuevas.
3. Escribe una o dos reglas propias para los errores típicos de tu proyecto: es la forma más rápida de obtener beneficio que los conjuntos generales no darán.