Cómo usar un LLM de forma segura en el trabajo de seguridad

Un asistente de IA puede resumir un registro de CVE en segundos. También puede dar la versión corregida equivocada con el mismo tono tranquilo que usa para la correcta. Este artículo trata esa brecha: los cuatro riesgos más importantes en el trabajo de seguridad, un método para mantenerlos acotados y un laboratorio en el que contrastas un resumen de ejemplo, escrito por IA, con el registro del NVD, el catálogo Known Exploited Vulnerabilities (KEV) de CISA y la página de seguridad de Apache Log4j.

La respuesta corta: usa el asistente para trabajo que puedas verificar, mantén los datos sensibles y las acciones reales fuera de su alcance a menos que alguien lo haya aprobado, y deja que una persona decida cada paso que cambie algo.

#Cuáles son los riesgos

Un asistente es un modelo de lenguaje con una caja de texto y, a menudo, algunas herramientas conectadas: búsqueda, lector de archivos, shell. Cuatro riesgos aparecen una y otra vez.

#Datos incorrectos dichos con mucha seguridad

Un modelo de lenguaje produce las palabras más plausibles a continuación. Muchas veces, la respuesta plausible también es verdadera. A veces es un número de versión que suena bien y no lo es. El perfil de IA generativa del NIST, el NIST AI 600-1, llama a esto confabulación: contenido presentado con seguridad pero que es erróneo o falso. El mismo documento explica que la confabulación surge de cómo se construyen estos modelos, no de un fallo raro.

Los identificadores son lo más expuesto. Los números de CVE, las versiones de paquetes, las fechas, los nombres de función, los números de RFC y de puerto parecen estructurados, así que un error en ellos parece verificado. Es fácil copiarlo en un ticket y difícil de notar después.

#Datos sensibles dentro del prompt

Todo lo que pegas en un prompt sale de tu control cuando llega a un servicio que tú no operas. Lo que pase después depende del servicio, de su configuración y de sus términos. El texto puede almacenarse, registrarse en logs o revisarse. En seguridad, el material de riesgo es conocido: nombres de clientes, nombres de host y rangos de IP internos, tokens que aparecen en logs, hallazgos no publicados y datos personales de un incidente. OWASP lo clasifica como LLM02:2025 Sensitive Information Disclosure, que cubre tanto lo que revela el modelo como lo que expone la aplicación que lo rodea.

#Acciones peligrosas con herramientas

Un asistente solo con caja de texto puede darte una respuesta mala. Un asistente con shell, token de API o permiso de escritura en un repositorio puede hacer algo malo de verdad. OWASP describe el problema en LLM06:2025 Excessive Agency: el sistema tiene más funciones, permisos o autonomía de los que la tarea necesita. Cuando el modelo entiende mal una petición, el daño depende de lo que tenía permitido tocar.

#Inyección de prompt desde contenido no confiable

La inyección de prompt ocurre cuando un contenido que el sistema lee como dato trae instrucciones, y el modelo las sigue. Ese contenido puede ser una página web que pediste resumir, un correo de tu bandeja, una línea de log con un user agent manipulado o un README de un repositorio que pediste revisar. OWASP lo trata como LLM01:2025 Prompt Injection. El perfil del NIST describe la forma indirecta, en la que un atacante deja instrucciones en datos que el asistente probablemente va a recuperar. El asistente puede no distinguir tu pedido del texto que acaba de leer.

#Por qué importa para los analistas

Los analistas son quienes copian el resultado de la IA en informes, reglas de detección, tickets y mensajes a clientes. El error viaja con la copia. Una versión corregida equivocada en tu resumen se convierte en una decisión de parche equivocada en la ventana de cambios de otra persona.

El AI Risk Management Framework del NIST, publicado el 26 de enero de 2023, organiza el trabajo en cuatro funciones: GOVERN, MAP, MEASURE y MANAGE. No necesitas un programa de IA para usar esa idea. Para un analista significa saber para qué sirve la herramienta, qué datos puede ver, con qué frecuencia se equivoca en tu tipo de tarea y quién aprueba una acción. El marco es voluntario, y está bien. Las preguntas siguen valiendo.

#El método

Cinco reglas, aplicadas en este orden cada vez.

#1. Decide qué puede entrar en el prompt

Antes de pegar cualquier cosa, separa el material en tres grupos:

• Público: avisos de fabricantes, registros de CVE publicados, documentación pública.
• Interno pero no sensible: un procedimiento genérico, un fragmento de código sin datos reales.
• Restringido: nombres de clientes, nombres de host, direcciones IP, credenciales, hallazgos no publicados, datos personales.

El material restringido queda fuera, salvo que el dueño de los datos haya aprobado ese uso y tu organización haya aprobado la herramienta para esa clase de dato. Si quieres que el asistente razone sobre un log, anonimízalo antes. Un sed basta para un caso rápido:

sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/10.x.x.x/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/user@example/g' incident.log > redacted.log

Ejecútalo sobre una copia, lee la salida y busca lo que la expresión no atrapa: nombres de host, usuarios, tokens y dominios internos. Una regex no sabe cómo tu cliente llama a sus servidores.

#2. Pide fuentes y separa los hechos de las suposiciones

Pide al asistente que liste cada afirmación factual con la fuente de donde sale, y que escriba "sin fuente" cuando no tenga una. Después trata cada afirmación sin fuente como una pregunta que tienes que responder tú.

Una cita en la respuesta no demuestra nada. El modelo puede producir un enlace plausible o una frase atribuida a un documento que nunca abrió. Abre el enlace. Lee el párrafo. Si el párrafo no dice lo que dice la respuesta, la respuesta está mal.

#3. Verifica contra datos primarios

Los datos primarios son el registro sobre el que trata la afirmación: la entrada del NVD para un CVE, el aviso del fabricante, la entrada del KEV de CISA, el texto de la norma, el resultado de tu propia prueba. Otra respuesta de IA no cuenta, porque la segunda puede repetir el mismo error con la misma seguridad. Usa el asistente para encontrar dónde mirar. Usa la fuente para decidir.

#4. Limita lo que la herramienta puede hacer

Empieza con acceso de solo lectura. Si la herramienta puede ejecutar comandos, dale una cuenta con el mínimo de permisos, una máquina virtual o contenedor desechable y una lista de comandos permitidos. Cualquier paso que escriba, envíe, borre o llame a un sistema activo debe esperar una confirmación. Guarda el registro de lo que se ejecutó. Lo vas a necesitar la primera vez que pase algo inesperado.

#5. Deja la decisión en manos de una persona

La herramienta propone. Una persona con contexto y autoridad decide, y anota qué aprobó y qué evidencia usó. Esto pesa más en acciones que no se pueden deshacer: bloquear un rango de IP, cerrar un ticket, publicar un parche en producción, enviar un mensaje a un cliente.

#Práctica: contrasta un resumen de CVE escrito por IA

Este laboratorio usa solo fuentes públicas y de solo lectura. No ejecutas nada contra un sistema en producción. Las tres consultas van al NVD, a CISA y a la Apache Software Foundation, y a ningún otro lugar.

Lo que necesitas: una terminal (Git Bash en Windows sirve), curl y jq. Si jq no está instalado, instálalo desde el sitio del proyecto jq. Los comandos de abajo se ejecutaron en Windows 11 con Git Bash. jq no estaba instalado en esa máquina, así que la salida que se muestra viene de un comando de Node.js que lee los mismos campos del JSON. Los comandos con jq son los que debes usar.

#El resumen de ejemplo

Este es un resumen que un asistente escribió sobre CVE-2021-44228, la falla conocida como Log4Shell. Léelo antes de comprobar nada y marca lo que creas que está mal.

CVE-2021-44228 es una falla de ejecución remota de código en Apache Log4j2. Un atacante que controla un valor registrado en log puede hacer que el servidor cargue código desde un servidor LDAP. El NVD publicó el registro el 2021-12-09. La falla afecta a Log4j desde la 2.13.0 hasta la 2.14.1, y actualizar a la 2.14.1 la corrige. La puntuación base de CVSS v3.1 es 10.0. CISA añadió la falla al catálogo KEV el 2021-12-10. Los atacantes empezaron a escanear pocas horas después de la divulgación. La falla está solo en log4j-core.

El resumen contiene dos errores deliberados. Encuéntralos con las fuentes de abajo.

#Paso 1: consulta el registro del NVD

La API del NVD devuelve el registro del CVE en JSON. Ejecuta:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' | jq '.vulnerabilities[0].cve | {published, descriptions: .descriptions[0].value}'

Comprobación equivalente sin jq, que es la salida que se muestra abajo:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' -o nvd.json
node -e "const c=JSON.parse(require('fs').readFileSync('nvd.json','utf8')).vulnerabilities[0].cve;console.log(JSON.stringify({published:c.published,descriptions:c.descriptions[0].value},null,2))"

Salida observada:

{
  "published": "2021-12-10T10:15:09.143",
  "descriptions": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects."
}

Mira el campo published. El resumen dice 2021-12-09. El registro dice 2021-12-10. Ese es el primer error.

La descripción también trae una condición que el resumen omitió: la carga de código ocurre cuando la sustitución de lookups en mensajes está habilitada. Omitirla hace que la falla parezca afectar a cualquier instalación de Log4j, y el registro no dice eso.

#Paso 2: consulta la entrada en KEV

CISA publica el catálogo KEV como un único archivo JSON. Descárgalo y filtra por el CVE:

curl -s -L 'https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json' -o kev.json
jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228")' kev.json

Salida observada, de un catálogo con versión 2026.11.06 y 1769 entradas, descargado el 2026-11-08 (el filtro jq se ejecutó con Node.js, como arriba):

{
  "cveID": "CVE-2021-44228",
  "vendorProject": "Apache",
  "product": "Log4j2",
  "vulnerabilityName": "Apache Log4j2 Remote Code Execution Vulnerability",
  "dateAdded": "2021-12-10",
  "shortDescription": "Apache Log4j2 contains a vulnerability where JNDI features do not protect against attacker-controlled JNDI-related endpoints, allowing for remote code execution.",
  "requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available.",
  "dueDate": "2021-12-24",
  "knownRansomwareCampaignUse": "Known",
  "forensicTriage": "No",
  "notes": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228",
  "cwes": [
    "CWE-20",
    "CWE-400",
    "CWE-502"
  ]
}

La entrada confirma la inclusión en KEV y la fecha de alta. No dice cuándo empezaron los escaneos y no nombra una versión corregida. Úsala para la inclusión, el plazo y la acción requerida, y nada más.

#Paso 3: abre la página de Apache y marca cada afirmación

El registro del NVD enlaza a la página de seguridad de Apache Log4j. Ábrela y busca la sección del CVE-2021-44228. Lee cuatro campos: versiones afectadas, versiones corregidas, componentes afectados y la descripción. En la versión de la página obtenida el 2026-11-08, la sección mostraba estos valores:

• Versiones afectadas: [2.0-beta9, 2.3.1), [2.4, 2.12.2) y [2.13.0, 2.15.0). Los corchetes son notación de intervalo: el extremo izquierdo entra y el derecho no, así que la propia 2.15.0 queda fuera del rango.
• Versiones corregidas: 2.3.1 para Java 6, 2.12.2 para Java 7 y 2.15.0 para Java 8 o superior.
• Componentes afectados: log4j-core.

Lee la página tú mismo, porque cambia. La página también tiene una sección aparte para el CVE-2021-45046, un problema posterior, que dice que la corrección de la 2.15.0 quedó incompleta en algunas configuraciones y apunta a la 2.16.0 para Java 8 o superior.

#Los veredictos

Marca cada afirmación del resumen como confirmada, incorrecta o no verificable. Este es el resultado de la comprobación.

Dos afirmaciones están mal, una no se puede verificar y el resto se confirma. Las dos incorrectas son los dos errores deliberados del resumen.

#Qué enseña la comprobación

El texto del NVD y los rangos de versiones no coinciden del todo. La descripción dice "through 2.15.0", mientras que el rango legible por máquina termina antes de la 2.15.0. Tanto la configuración del NVD como la página de Apache dicen que la 2.15.0 no está afectada por este CVE en Java 8 o superior. Cuando las fuentes no coinciden, anota la diferencia y cita la que define el rango. No elijas la versión que queda mejor en el texto.

La versión corregida depende de la versión de Java y del CVE. Un único número de "corregido en" oculta las dos cosas. Pide el CVE exacto, el producto, el componente y la plataforma, y lee la tabla del fabricante.

"No verificable" es un veredicto útil. El resumen afirma algo sobre el tiempo de los atacantes que ninguna de tus fuentes da. Esa afirmación puede ser cierta, y puede estar en una fuente que no leíste. En un informe necesita su propia cita o debe salir.

#Errores comunes

• Confiar en la forma de una cita. Un enlace bien armado, con un título plausible, puede llevar a una página que dice otra cosa. Ábrelo.
• Pegar un incidente completo para tener una "mirada rápida". Anonimiza primero y pega solo el fragmento que necesita la pregunta.
• Pedir la "última versión" sin fecha. Un modelo puede no saber de lanzamientos posteriores al final de sus datos de entrenamiento. Dale las notas de versión o el aviso y pide que los lea.
• Aceptar un parche generado sin ejecutar las pruebas ni leer el diff.
• Probar cómo maneja el asistente datos reales de un cliente "solo para ver". La prueba ya es la fuga.
• Dar credenciales de producción a un agente porque la demo las necesitaba.
• Resumir una página web sin pensar en quién la escribió. La página puede traer instrucciones. Trata su texto como un dato que se lee, no como una orden que se obedece.

#Cómo seguir

Arma una evaluación pequeña para tu propio trabajo. Elige veinte CVE cuya respuesta ya conoces, pide al asistente un resumen de cada uno y cuenta los errores por tipo: fechas, versiones, componentes, puntuaciones. Una comprobación pequeña así dice más sobre tus tareas que la demo de cualquier fabricante. Repítela cuando cambie la herramienta o tu tarea.

Lee las entradas de OWASP para LLM01, LLM02, LLM06 y LLM09. Dan un vocabulario común para la inyección de prompt, la exposición de datos, los permisos excesivos y la desinformación. Después lee la sección 2 del NIST AI 600-1, que define los riesgos que cubre el perfil.

Si todavía estás en los fundamentos, lee ¿Qué es una vulnerabilidad? y ¿Qué es CVSS?. Para practicar la escritura de los hallazgos que verificaste, lee Cómo escribir tu primer informe de seguridad. Si envías trabajo a un modelo a través de la API de NotHoly, las mismas cinco reglas valen para lo que envías.

#Fuentes

• NIST AI Risk Management Framework
• NIST AI 600-1, Generative AI Profile (julio de 2024)
• OWASP Top 10 for LLM and GenAI Applications, 2025
• Documentación de la API de vulnerabilidades del NVD
• Registro del NVD para CVE-2021-44228
• Catálogo Known Exploited Vulnerabilities de CISA (feed JSON)
• Apache Log4j Security Vulnerabilities