Entrar Pedir acceso a la beta Pedir acceso
El sector lo llamaSAST Qué revisa · 1 de 7

El código que te escribe la IA

Una IA escribe código que funciona a la primera, y por eso nadie lo lee entero. Las vulnerabilidades que deja no son raras: son las de siempre, escritas más rápido. Vibethia lee cada cambio buscándolas y te señala la línea.

Léelo en
Para quien programa con IA y quiere entender el riesgo, sin siglas. Para quien ya conoce SAST: motor, cobertura, pipeline y límites.
El riesgo

Funciona. Y devuelve las facturas de otro

El código que te escribe la IA pasa los tests porque hace lo que le pediste. Lo que no le pediste (comprobar quién pregunta, desconfiar de lo que llega) no lo pone si no se lo dices. Y casi nadie se lo dice.

Cuatro líneas, un minuto. Nadie comprueba que ese cliente seas tú: cambia el número y ves las de otro.
VibethiaCorregirDevuelve datos sin comprobar de quién son. app/api/facturas · línea 3.

  • Datos de otro a un número de distancia

    Una ruta que devuelve lo que le pidas por su id, sin comprobar que sea tuyo. La IA lo escribe así porque funciona.

  • La consulta armada con lo que llega

    Un texto de la petición pegado dentro de una consulta a la base de datos. Quien lo manda puede cambiar la consulta.

  • La dirección que elige el usuario

    Tu servidor pide una URL que viene de fuera, o redirige a donde le digan. Sirve para llegar a tu red interna o para engañar a tus usuarios.

  • La contraseña mal guardada

    Guardada con un cifrado rápido de los años noventa, o comparada letra a letra. Si se filtra la base, se recuperan.

  • El valor por defecto que se queda

    La clave de sesión que vale «changeme» si nadie pone otra. Nadie pone otra.

Qué hace Vibethia

Lee cada cambio y te señala la línea

En cada subida, un lector automático recorre tu código buscando estos patrones. Avisa de más, a propósito. Después el analista mira cada aviso con el código delante y aparta las falsas alarmas: a ti te llega lo que hay que corregir, con la línea y el porqué.

  • Busca lo de siempre. Cientos de patrones públicos que la comunidad mantiene, más los nuestros para lo que más vemos en código escrito con IA.
  • No te manda la lista cruda. De cada aviso, el analista lee el trozo de código y lo que lo rodea. Si la consulta va protegida o el dato ya está validado, lo descarta y dice por qué.
  • Te lo explica. Qué puede pasar, si es urgente y cómo se arregla, con un prompt prudente para tu IA. Así es una ficha.
  • Y lo que ningún patrón ve. La lógica de tu app (quién puede leer qué) la mira aparte una capa de reglas propias y, si la activas, una revisión con IA de los puntos de entrada.
Medido

Lo que vio y lo que no

En nuestro repo de pruebas sembramos 20 vulnerabilidades de código. Nuestras herramientas vieron 13. El plan gratuito de Xygeni, 16. Lo decimos porque es lo que hay, y porque las cuatro que se nos escaparon ya tienen regla propia.

  • Vulnerabilidades de código vistas 13 de 20.

    Las cuatro que faltaron: dos peticiones a direcciones que elige el usuario, una redirección abierta y un cifrado de contraseñas débil.

  • Falsas alarmas que quedaron tras el triaje 5 de 24.

    Frente a 14 de 24 en Xygeni, que no quita ninguna.

La comparativa entera, línea a línea.

Motor

Semgrep, con reglas públicas y cinco propias

Análisis estático por patrones, en vuestras Actions. Sin build, sin ejecutar nada; el fragmento señalado viaja a la API y el resto se queda en GitHub.

Escáner
Semgrep OSS, en el runner, con salida SARIF.
Reglas públicas
p/default y p/expressjs. Entran también las de GitHub Actions (acciones sin fijar, inyección en run) y las de Kubernetes.
Reglas propias
Genéricas, nunca a la medida del repo de pruebas, y cada una con su test (pnpm reglas:probar):
Lenguajes
Los que cubre Semgrep: JavaScript y TypeScript, Python, Go, Java, PHP, Ruby, C#, Kotlin, Rust y otros. Las reglas propias están escritas para JavaScript/TypeScript y Python.
  • Propia sql_unsafe_interpolado

    Consulta armada con texto que llega de fuera.

  • Propia ssrf

    Petición del servidor a una dirección que elige el usuario.

  • Propia redireccion_abierta

    Redirección a un destino que llega de la petición.

  • Propia contrasena_hash_rapido

    Contraseñas con un hash rápido (MD5, SHA-1) en lugar de uno lento.

  • Propia secreto_por_defecto

    Secreto con valor por defecto si falta la variable de entorno.

Contexto

Lo que viaja: el fragmento, no el repo

El workflow adjunta a cada resultado el trozo de código alrededor de la línea señalada, ya enmascarado. El analista recibe eso y nada más.

Hallazgo
Regla, mensaje de cada escáner que lo vio, CWE, severidad base y ruta:líneas.
Fragmento
±20 líneas numeradas, con » en las señaladas, como en el panel. Antes pasa por las capas de enmascarado de secretos.
Deduplicación
Huella estable sin número de línea; las reglas que son la misma cosa en dos escáneres se funden. Un hallazgo que sigue en la siguiente subida se reconoce.
Lo que no viaja
El repo entero, los ficheros no señalados y cualquier secreto sin enmascarar. Excluidos por defecto: dependencias instaladas, builds y fixtures.
Triaje

Lo que hace el analista con un aviso de código

  • Explotable Camino plausible desde fuera

    Desde algo que controla un atacante (petición, fichero, entorno expuesto) hasta la línea señalada. Veredicto Corregir, por severidad.

  • Improbable Existe, pero no se llega

    Entrada constante o validada antes, código solo de test o de desarrollo. Vigilar, o Revisar si la confianza es baja.

  • Falso positivo El patrón no está o está neutralizado

    Consulta parametrizada, escapado correcto para ese contexto. Descartar, con el porqué.

  • No Análisis de flujo entre ficheros

    El analista ve el fragmento y lo que el workflow adjunta, no el grafo del programa. Una validación tres ficheros más allá puede no verla: por eso Improbable con confianza baja va a Revisar.

Límites

Lo que esta capa no hace

  • No Taint tracking entre módulos

    Semgrep OSS corre en modo patrón; no hay análisis interprocedural ni de flujo global.

  • No Compilar ni ejecutar

    No hace falta build. Tampoco se detecta lo que solo se ve en ejecución.

  • Todavía no Reglas propias por cliente

    Las reglas propias son las mismas para todos. Políticas por repo, en camino.

  • Medido Repo de pruebas

    13 de 20 vulnerabilidades de código (Xygeni gratuito: 16 de 20); 5 de 24 falsos positivos quedaron tras el triaje (Xygeni: 14 de 24). La tabla.

Lo demás que revisa

Del ruido a la decisión

Conecta un repo y mira qué hay que corregir. Sin hablar con nadie.

Pedir acceso a la beta