Crear cuenta gratuita
Seguridad del código de aplicaciones LLM

La salida de su modelo es una entrada no confiable. Encuentre dónde su código lo olvida.

Análisis estático del código que rodea a su LLM — el código que construye el prompt, llama al modelo y hace algo con la respuesta. No el modelo. No la resistencia del prompt a un jailbreak. El código.

El plan gratuito cubre 3 proyectos y 30 análisis al mes, sin límite de usuarios y sin tarjeta de crédito. Este análisis se ejecuta en él.

El problema

Un modelo no es una biblioteca. Es un intérprete no confiable: usted le entrega una cadena y él le devuelve otra. Todo lo que influyó en esa cadena — el propio prompt del usuario, una página que se le mostró, un documento que se le dio, el resultado de otra herramienta — influyó en la respuesta.

La respuesta es inofensiva hasta que el código le da una capacidad. El peligro no es que un modelo haya dicho algo; es que un programa se lo haya creído. Cada lugar donde un programa trata el texto generado como código, como un comando, como una consulta, como una ruta o como una URL es una inyección con un salto más — y, a diferencia de la cuestión de si un prompt puede ser vulnerado con un jailbreak, ese salto es visible en el código fuente.

Qué busca Cybseco

Dónde la salida del modelo llega a algo que actúa. Estas son las categorías, severidades e identificadores CWE propios del motor.

Ejecución de código — CWE-94
crítica
eval, exec, compile, new Function, pickle.loads, yaml.load — la respuesta se convierte en un programa.
Un shell — CWE-78
crítica
os.system, subprocess, child_process.exec, execSync — la respuesta se convierte en un comando.
Una consulta SQL — CWE-89
alta
execute, raw, createQuery — el text-to-SQL es exactamente este patrón, y DROP TABLE es una terminación plausible.
Una ruta del sistema de archivos — CWE-22
alta
open, readFile, shutil.rmtree, unlink — ../../etc/passwd también es una terminación plausible.
Una petición saliente — CWE-918
alta
requests, httpx, fetch, axios, urlopen — falsificación de peticiones del lado del servidor, elegida por el modelo.

Un ejemplo concreto

Nueve líneas, y toda la forma del riesgo.

from openai import OpenAI
client = OpenAI()

def run_plan(task: str):
    answer = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": task}],
    )
    exec(answer.choices[0].message.content)
Origen
client.chat.completions.create(…) — una llamada que devuelve salida del modelo. El analizador vincula la variable a la que se asignó, que es lo que le permite seguir el valor a lo largo de la función sin análisis interprocedural.
Flujo
answer contiene texto influido por un atacante. Entre la llamada y el sumidero nada lo inspecciona, lo restringe ni lo limita a un conjunto fijo de operaciones.
Sumidero
exec(…) — el texto se convierte en un programa dentro del propio proceso de la aplicación, con sus credenciales, su red y su sistema de archivos.
Por qué importa
Cualquier cosa capaz de influir en task — directamente o a través de un documento mostrado al modelo — elige qué se ejecuta. Esto es ejecución remota de código con un salto más.

Ejecutado contra el motor actual, ese fragmento produce un hallazgo: llm-output-to-code-execution, CWE-94, severidad crítica, confianza alta, en la línea exec. La confianza es alta porque la variable está vinculada a una llamada de completado real. Un nombre que solo parece una respuesta del modelo — llm_response, reply — se reporta con confianza media, porque eso es una suposición y afirmar lo contrario sería mentir sobre la evidencia.

Lo que esto no es

No es una prueba del modelo
No sondeamos el modelo, no le hacemos red teaming ni evaluamos cómo se comporta bajo presión. Nada aquí dice si un prompt puede ser vulnerado con un jailbreak: eso no es decidible desde el código fuente, y afirmarlo sería exactamente el tipo de declaración que este motor existe para evitar.
No es una detección completa de inyección de prompts
La inyección indirecta se reporta allí donde contenido no confiable llega de forma demostrable a un prompt. Un canal que no podemos ver en el código es un canal que no reportamos.
No es una garantía sobre un agente
Reportamos que a un agente se le concedió una herramienta que ejecuta código o comandos. Lo que el agente haga después en tiempo de ejecución queda fuera de lo que el análisis estático puede decidir.
Complementario a la seguridad de la IA en ejecución
Los guardrails, los bancos de evaluación y el red teaming responden preguntas que esto no puede responder, y esto responde preguntas que ellos no pueden. Ninguno sustituye al otro.

Otros riesgos específicos de LLM en el código

Cada uno se activó sobre una muestra contra el motor actual antes de escribirse aquí.

Secretos y datos personales interpolados en un prompt — CWE-200
Una api_key, una contraseña, un IBAN o un historial médico colocados en el texto que usted envía. Se reporta donde realmente se construye un contexto de prompt, no en cualquier f-string que resulte contener una clave.
Un agente al que se le dio una herramienta que ejecuta código o comandos — CWE-250
PythonREPLTool, ShellTool, un intérprete de código, un terminal. Conceder una de ellas convierte toda pregunta sobre inyección de prompts en una pregunta sobre ejecución remota de código.
Una salvaguarda del framework vuelta a desactivar — CWE-502
allow_dangerous_deserialization=True, trust_remote_code=True, dangerouslyAllow… — un framework lo desactivó porque era inseguro.
Controles de seguridad del proveedor desactivados — CWE-693
BLOCK_NONE, safety_settings=None, moderation=false.
Un prompt o una definición de agente obtenidos en tiempo de ejecución — CWE-829
hub.pull(…), una plantilla de prompt cargada por HTTP. Quien controla ese endpoint controla las instrucciones.
Contenido no confiable cargado directamente en un prompt — CWE-77
Una página extraída de la web, un PDF, un repositorio, un wiki. Este es el canal de inyección indirecta, reconocido por la procedencia del texto y no por lo que dice.
Una clave de API de modelo escrita en el código fuente — CWE-798
sk-…, sk-ant-…, AIza…, hf_… subidos al repositorio.
Un modelo retirado o sustituido fijado en el código — CWE-1104
text-davinci-*, gpt-4-0314, claude-instant — jerarquía de instrucciones más débil, sin separación del prompt de sistema.

Por qué creer nada de esto

Un benchmark publicado
Precisión, exhaustividad y F1 por CWE, por lenguaje y por capa de análisis, sobre un corpus versionado y etiquetado a mano. Ver las cifras.
Un perímetro publicado
Cada capa que no medimos está nombrada, con el motivo. Leer la metodología.
Validación sobre código público
Repositorios y commits analizados, lenguajes encontrados, tasa de finalización y determinismo — volúmenes y tasas, no afirmaciones de precisión. Ver las ejecuciones.
Cada hallazgo lleva su evidencia
El archivo, la línea, la construcción detectada y el CWE. Un hallazgo que no puede comprobar es un hallazgo sobre el que no debería actuar.

Independiente del proveedor por construcción. El analizador reconoce la forma — algo produce texto, algo lo consume — en lugar de la escritura de un SDK concreto. Nombra el framework que vio cuando puede (OpenAI, Anthropic, Google, Azure OpenAI, Mistral, Bedrock, Ollama, LiteLLM, LangChain, LangGraph, LlamaIndex, Semantic Kernel, AutoGen, CrewAI, Hugging Face) para que un hallazgo pueda decir de dónde viene. Eso es una etiqueta en el hallazgo, no una integración por SDK, y un framework ausente de esa lista se analiza exactamente igual.

Vea a Cybseco razonar sobre un sistema real

Vea la demo interactiva y luego solicite una prueba guiada para su equipo.