Como usar um LLM com segurança no trabalho de segurança

Um assistente de IA resume um registro de CVE em segundos. Ele também pode dar a versão corrigida errada no mesmo tom tranquilo que usa para a certa. Este artigo trata dessa diferença: os quatro riscos mais importantes no trabalho de segurança, um método para deixá-los pequenos e um laboratório em que você confere um resumo de exemplo, escrito por IA, com o registro do NVD, o catálogo Known Exploited Vulnerabilities (KEV) da CISA e a página de segurança do Apache Log4j.

A resposta curta: use o assistente em trabalhos que você consegue conferir, mantenha dados sensíveis e ações reais fora do alcance dele, a menos que alguém tenha aprovado, e deixe uma pessoa decidir cada passo que altera alguma coisa.

#Quais são os riscos

Um assistente é um modelo de linguagem com uma caixa de texto e, muitas vezes, algumas ferramentas conectadas: busca, leitor de arquivos, shell. Quatro riscos aparecem sempre.

#Fatos errados com muita confiança

Um modelo de linguagem produz as palavras mais plausíveis que vêm em seguida. Muitas vezes, a resposta plausível também é verdadeira. Às vezes é um número de versão que soa certo e não é. O perfil de IA generativa do NIST, o NIST AI 600-1, chama isso de confabulação: conteúdo apresentado com segurança, mas errado ou falso. O mesmo documento explica que a confabulação decorre de como esses modelos são construídos, não de um defeito raro.

Os identificadores são o ponto mais frágil. Números de CVE, versões de pacote, datas, nomes de função, números de RFC e de porta parecem estruturados, então um erro nelas parece verificado. É fácil copiar para um ticket e difícil de notar depois.

#Dados sensíveis dentro do prompt

Tudo o que você cola num prompt sai do seu controle quando chega a um serviço que você não opera. O que acontece depois depende do serviço, das configurações e dos termos dele. O texto pode ser armazenado, registrado em log ou revisado. Na segurança, o material de risco é conhecido: nomes de clientes, nomes de host e faixas de IP internas, tokens que aparecem em logs, achados ainda não publicados e dados pessoais de um incidente. A OWASP classifica isso em LLM02:2025 Sensitive Information Disclosure, que cobre tanto o que o modelo revela quanto o que a aplicação ao redor expõe.

#Ações perigosas de ferramentas

Um assistente só com caixa de texto dá, no pior caso, uma resposta ruim. Um assistente com shell, token de API ou permissão de escrita num repositório pode fazer algo ruim de verdade. A OWASP descreve o problema em LLM06:2025 Excessive Agency: o sistema tem mais funções, permissões ou autonomia do que a tarefa exige. Quando o modelo entende mal um pedido, o estrago depende do que ele podia tocar.

#Injeção de prompt vinda de conteúdo não confiável

A injeção de prompt acontece quando um conteúdo que o sistema lê como dado traz instruções, e o modelo passa a segui-las. Esse conteúdo pode ser uma página web que você pediu para resumir, um e-mail da sua fila, uma linha de log com um user agent forjado ou um README de um repositório que você mandou revisar. A OWASP trata isso em LLM01:2025 Prompt Injection. O perfil do NIST descreve a forma indireta, em que um atacante deixa instruções em dados que o assistente provavelmente vai recuperar. O assistente pode não distinguir o seu pedido do texto que acabou de ler.

#Por que isso importa para analistas

Analistas são quem copia o resultado da IA para relatórios, regras de detecção, tickets e mensagens a clientes. O erro vai junto com a cópia. Uma versão corrigida errada no seu resumo vira uma decisão errada de patch na janela de mudança de outra pessoa.

O AI Risk Management Framework do NIST, publicado em 26 de janeiro de 2023, organiza o trabalho em quatro funções: GOVERN, MAP, MEASURE e MANAGE. Você não precisa ter um programa de IA para usar essa ideia. Para um analista, ela significa saber para que a ferramenta serve, quais dados ela pode ver, com que frequência erra no seu tipo de tarefa e quem aprova uma ação. O framework é voluntário, e tudo bem. As perguntas continuam valendo.

#O método

Cinco regras, aplicadas nessa ordem toda vez.

#1. Decida o que pode entrar no prompt

Antes de colar qualquer coisa, separe o material em três grupos:

• Público: avisos de fornecedores, registros de CVE publicados, documentação pública.
• Interno, mas não sensível: um procedimento genérico, um trecho de código sem dados reais.
• Restrito: nomes de clientes, nomes de host, endereços IP, credenciais, achados não publicados, dados pessoais.

O material restrito fica de fora, a menos que o dono dos dados tenha aprovado esse uso e a sua organização tenha aprovado a ferramenta para essa classe de dado. Se você quer que o assistente raciocine sobre um log, anonimize antes. Um sed resolve um 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

Rode isso numa cópia, leia a saída e procure o que a expressão não pega: nomes de host, usuários, tokens e domínios internos. A regex não sabe como o seu cliente chama os servidores dele.

#2. Peça fontes e separe fatos de palpites

Peça ao assistente que liste cada afirmação factual com a fonte de onde ela veio e que escreva "sem fonte" quando não tiver uma. Depois trate cada afirmação sem fonte como uma pergunta que você precisa responder.

Uma citação na resposta não prova nada. O modelo pode produzir um link plausível ou uma frase atribuída a um documento que nunca abriu. Abra o link. Leia o parágrafo. Se o parágrafo não diz o que a resposta diz, a resposta está errada.

#3. Confira nos dados primários

Dados primários são o registro sobre o qual a afirmação fala: a entrada do NVD para um CVE, o aviso do fornecedor, a entrada do KEV da CISA, o texto da norma, o resultado do seu próprio teste. Outra resposta de IA não conta, porque a segunda pode repetir o mesmo erro com a mesma confiança. Use o assistente para descobrir onde olhar. Use a fonte para decidir.

#4. Limite o que a ferramenta pode fazer

Comece com acesso somente leitura. Se a ferramenta pode rodar comandos, dê a ela uma conta com o mínimo de permissões, uma máquina virtual ou contêiner descartável e uma lista de comandos permitidos. Qualquer passo que escreva, envie, apague ou chame um sistema vivo deve esperar uma confirmação. Guarde o registro do que foi executado. Você vai querer esse registro na primeira vez que algo inesperado acontecer.

#5. Mantenha a decisão com uma pessoa

A ferramenta propõe. Uma pessoa com contexto e autoridade decide, e registra o que aprovou e a evidência que usou. Isso pesa mais em ações que não se desfazem: bloquear uma faixa de IP, fechar um ticket, publicar um patch em produção, enviar uma mensagem ao cliente.

#Na prática: confira um resumo de CVE escrito por IA

Este laboratório usa apenas fontes públicas e somente leitura. Você não executa nada contra um sistema em produção. As três consultas vão para o NVD, para a CISA e para a Apache Software Foundation, e para mais nenhum lugar.

O que você precisa: um terminal (o Git Bash no Windows funciona), curl e jq. Se o jq não estiver instalado, instale pelo site do projeto jq. Os comandos abaixo foram executados no Windows 11 com Git Bash. O jq não estava instalado nessa máquina, então a saída mostrada vem de um comando Node.js que lê os mesmos campos do JSON. Os comandos com jq são os que você deve usar.

#O resumo de exemplo

Abaixo está um resumo que um assistente escreveu sobre o CVE-2021-44228, a falha conhecida como Log4Shell. Leia antes de conferir qualquer coisa e marque o que você acha que está errado.

O CVE-2021-44228 é uma falha de execução remota de código no Apache Log4j2. Um atacante que controla um valor registrado em log consegue fazer o servidor carregar código de um servidor LDAP. O NVD publicou o registro em 2021-12-09. A falha afeta o Log4j de 2.13.0 até 2.14.1, e atualizar para 2.14.1 a corrige. A pontuação base do CVSS v3.1 é 10.0. A CISA incluiu a falha no catálogo KEV em 2021-12-10. Atacantes começaram a fazer varreduras em poucas horas após a divulgação. A falha está apenas no log4j-core.

O resumo tem dois erros deliberados. Encontre-os com as fontes abaixo.

#Passo 1: busque o registro no NVD

A API do NVD devolve o registro do CVE em JSON. Rode:

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}'

Verificação equivalente sem jq, que é a saída mostrada abaixo:

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))"

Saída 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."
}

Olhe o campo published. O resumo diz 2021-12-09. O registro diz 2021-12-10. Esse é o primeiro erro.

A descrição também traz uma condição que o resumo deixou de fora: o carregamento de código acontece quando a substituição de lookup de mensagem está habilitada. Deixar isso de fora faz a falha parecer atingir qualquer instalação do Log4j, e o registro não diz isso.

#Passo 2: busque a entrada no KEV

A CISA publica o catálogo KEV como um único arquivo JSON. Baixe e filtre pelo 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

Saída observada, de um catálogo com versão 2026.11.06 e 1769 entradas, baixado em 2026-11-08 (o filtro jq foi executado pelo Node.js, como acima):

{
  "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"
  ]
}

A entrada confirma a inclusão no KEV e a data de inclusão. Ela não diz quando as varreduras começaram e não informa uma versão corrigida. Use-a para a inclusão, o prazo e a ação exigida, e nada além disso.

#Passo 3: abra a página do Apache e marque cada afirmação

O registro do NVD aponta para a página de segurança do Apache Log4j. Abra e encontre a seção do CVE-2021-44228. Leia quatro campos: versões afetadas, versões corrigidas, componentes afetados e a descrição. Na versão da página obtida em 2026-11-08, a seção trazia estes valores:

• Versões afetadas: [2.0-beta9, 2.3.1), [2.4, 2.12.2) e [2.13.0, 2.15.0). Os colchetes são notação de intervalo: a ponta esquerda entra e a direita não, então a própria 2.15.0 fica fora da faixa.
• Versões corrigidas: 2.3.1 para Java 6, 2.12.2 para Java 7 e 2.15.0 para Java 8 ou superior.
• Componentes afetados: log4j-core.

Leia a página você mesmo, porque ela muda. A página também tem uma seção separada para o CVE-2021-45046, um problema posterior, que diz que a correção de 2.15.0 ficou incompleta em algumas configurações e aponta 2.16.0 para Java 8 ou superior.

#Os veredictos

Marque cada afirmação do resumo como confirmada, errada ou não verificável. Este é o resultado da conferência.

Duas afirmações estão erradas, uma não pode ser verificada e as demais conferem. As duas erradas são os dois erros deliberados do resumo.

#O que a conferência ensina

O texto do NVD e as faixas de versão divergem de um jeito pequeno. A descrição diz "through 2.15.0", enquanto a faixa lida por máquina termina antes de 2.15.0. Tanto a configuração do NVD quanto a página do Apache dizem que 2.15.0 não é afetada por esse CVE em Java 8 ou superior. Quando as fontes divergem, registre a divergência e cite a que define a faixa. Não escolha a versão que fica melhor no texto.

A versão corrigida depende da versão do Java e do CVE. Um único número de "corrigido em" esconde as duas coisas. Peça o CVE exato, o produto, o componente e a plataforma, e leia a tabela do fornecedor.

Não verificável é um veredicto útil. O resumo afirma algo sobre o tempo dos atacantes que nenhuma das suas fontes dá. Essa afirmação pode ser verdadeira, e pode estar numa fonte que você não leu. Num relatório, ela precisa de citação própria ou precisa sair.

#Erros comuns

• Confiar na aparência de uma citação. Um link bonito, com um título plausível, pode levar a uma página que diz outra coisa. Abra.
• Colar um incidente inteiro para ter uma "olhada rápida". Anonimize antes e cole só o trecho que a pergunta precisa.
• Pedir a "versão mais recente" sem data. Um modelo pode não saber de lançamentos posteriores ao fim dos dados de treinamento. Dê a ele as notas de versão ou o aviso e peça que leia.
• Aceitar um patch gerado sem rodar os testes e sem ler o diff.
• Testar como o assistente lida com dados reais de cliente "só para ver". O teste já é o vazamento.
• Dar credenciais de produção a um agente porque a demonstração precisava delas.
• Resumir uma página web sem pensar em quem a escreveu. A página pode trazer instruções. Trate o texto como dado a ser lido, não como ordem a ser seguida.

#Como continuar

Monte uma avaliação pequena para o seu próprio trabalho. Escolha vinte CVEs cuja resposta você já conhece, peça ao assistente um resumo de cada um e conte os erros por tipo: datas, versões, componentes, pontuações. Uma checagem pequena assim diz mais sobre as suas tarefas do que a demonstração de um fornecedor. Repita quando a ferramenta ou a sua tarefa mudar.

Leia as entradas da OWASP para LLM01, LLM02, LLM06 e LLM09. Elas dão um vocabulário comum para injeção de prompt, exposição de dados, permissões excessivas e desinformação. Depois leia a seção 2 do NIST AI 600-1, que define os riscos cobertos pelo perfil.

Se você ainda está nos fundamentos, leia O que é uma vulnerabilidade? e O que é CVSS?. Para praticar a escrita dos achados que você verificou, leia Como escrever seu primeiro relatório de segurança. Se você envia trabalho a um modelo pela API da NotHoly, as mesmas cinco regras valem para o que você envia.

#Fontes

• NIST AI Risk Management Framework
• NIST AI 600-1, Generative AI Profile (julho de 2024)
• OWASP Top 10 for LLM and GenAI Applications, 2025
• Documentação da API de vulnerabilidades do NVD
• Registro do NVD para o CVE-2021-44228
• Catálogo Known Exploited Vulnerabilities da CISA (feed JSON)
• Apache Log4j Security Vulnerabilities