Como preparar a divulgação de vulnerabilidades para relatos gerados ou assistidos por IA

Introdução

Um pesquisador envia um relatório detalhado: descrição da falha, classificação de severidade, trecho de código e uma suposta prova de conceito. O texto parece consistente. Ao investigar, porém, a equipe descobre que a função citada não existe naquela versão, o comportamento depende de uma configuração ausente e a prova de conceito nunca foi executada.

Outro relatório, escrito com auxílio da mesma categoria de ferramenta, identifica uma falha real de autorização entre clientes.

Esse é o desafio: a qualidade da redação deixou de ser um bom indicador da qualidade da evidência.

A inteligência artificial pode ajudar a encontrar vulnerabilidades, organizar resultados e reduzir barreiras de comunicação. Também pode produzir hipóteses incorretas com aparência de conclusões verificadas. O processo de divulgação precisa absorver ambos os casos sem desperdiçar a capacidade de engenharia nem descartar descobertas legítimas.

Este artigo apresenta um fluxo de recebimento, triagem, reprodução e divulgação coordenada. O laboratório em Google Kubernetes Engine — GKE — aparece como ambiente isolado para validar evidências. Aprendizado por reforço, ou _Reinforcement Learning_ — RL — entra apenas como possibilidade de pesquisa sobre agentes de triagem, separada do processo operacional.

O que é divulgação coordenada de vulnerabilidades

A divulgação coordenada de vulnerabilidades, ou _Coordinated Vulnerability Disclosure_ — CVD — organiza a interação entre pesquisadores, responsáveis pelo produto e, quando necessário, fornecedores e coordenadores externos.

O trabalho envolve receber o relato, avaliar sua validade, corrigir o problema e comunicar informações úteis aos usuários afetados. A coordenação é especialmente importante quando uma falha envolve vários produtos ou organizações. O guia do CERT Coordination Center apresenta esse processo como uma atividade com múltiplos participantes e responsabilidades.

Três conceitos devem ser separados:

Uma organização pode manter VDP e CVD sem oferecer recompensas.

Para relatos assistidos por IA, a mudança principal está na entrada: o processo precisa distinguir observação, hipótese e conclusão, preservando a responsabilidade de quem envia e de quem valida.

Principais conceitos

Evidência reproduzível

É um conjunto de informações que permite verificar o comportamento relatado: versão, configuração, pré-condições, procedimento e resultado observado.

Uma prova de conceito, ou _Proof of Concept_ — PoC — pode ajudar, mas não deve ser obrigatoriamente um exploit completo. Um teste mínimo ou uma análise de código demonstrável pode ser suficiente para iniciar a investigação.

A equipe também não deve exigir acesso a dados reais de terceiros para comprovar impacto.

Procedência e revisão

Registre se a IA ajudou na descoberta, no código de teste, na análise ou apenas na redação. Isso informa a revisão; não determina a validade.

O ponto relevante é saber quais afirmações foram verificadas por uma pessoa e quais permanecem hipóteses. Não é necessário exigir o histórico integral de prompts, que pode conter informações confidenciais.

Severidade e confiança

Severidade expressa o impacto e as condições de exploração. Confiança expressa a força das evidências disponíveis.

Um relato pode alegar impacto crítico e ainda ter baixa confiança. Outro pode comprovar uma falha de impacto limitado.

O Common Vulnerability Scoring System — CVSS — pode apoiar a classificação técnica, mas o vetor precisa ser revisado com base no comportamento confirmado. Uma pontuação sugerida por IA não substitui essa análise.

Conteúdo não confiável

Texto, anexos, URLs e código enviados por pesquisadores são entradas não confiáveis.

Isso inclui instruções inseridas para manipular um modelo de linguagem, ou _Large Language Model_ — LLM. A OWASP descreve esse problema como _prompt injection_, incluindo ataques indiretos em documentos e conteúdos externos.

Prepare a política antes de automatizar

A política pública deve informar:

• Quais produtos, versões e ambientes estão no escopo.
• Quais testes são permitidos e quais exigem autorização específica.
• Como enviar informações sensíveis.
• Quais evidências ajudam na análise.
• Como funcionam atualizações de status e divulgação pública.
• Quais regras existem para automação e uso de IA.

Uma formulação operacional possível é:

Relatos assistidos por IA são aceitos. Diferencie resultados observados de hipóteses, informe as etapas verificadas e forneça evidências suficientes para análise. Não execute testes fora do escopo autorizado nem envie dados de terceiros desnecessários à comprovação.

Essa formulação é uma proposta para adaptação, não um texto jurídico pronto.

Regras sobre pesquisa de boa-fé devem refletir a autorização efetiva da organização. A política não pode prometer permissões sobre infraestrutura de terceiros.

Publique um security.txt

O RFC 9116 define um formato para divulgar contatos e referências de segurança em /.well-known/security.txt. Os campos Contact e Expires são obrigatórios; o arquivo deve ser servido por HTTPS.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-04-07T23:59:59Z
Preferred-Languages: pt-BR, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/disclosure-policy

Substitua domínio, contatos e validade. Sirva o arquivo como text/plain e monitore sua expiração.

O arquivo facilita encontrar o canal correto; os critérios de pesquisa e tratamento pertencem à política referenciada.

Arquitetura e funcionamento

Uma arquitetura adequada mantém o recebimento disponível e controla separadamente o trabalho de investigação.

Recebimento
   ↓
Registro e quarentena
   ↓
Triagem de escopo e evidências  ←──────────────┐
   ↓                                           │
Próxima ação ──→ Solicitar complemento ────────┘
   ↓
Reprodução isolada
   ↓
Validação humana
   ↓
Correção e reteste
   ↓
Divulgação coordenada

O portal recebe o relato, atribui um identificador e armazena anexos com acesso restrito. Uma fila desacopla a entrada dos workers de análise.

Verificações determinísticas conferem tamanho, formato e campos. A IA pode produzir resumos ou sugerir duplicatas, mas suas respostas permanecem recomendações.

A reprodução ocorre em ambiente autorizado. Depois, um responsável confirma validade, impacto e prioridade. Engenharia prepara a correção; o reteste verifica tanto a eliminação da falha quanto possíveis regressões.

O modelo não deve controlar sozinho execução de código, encerramento do relato, publicação ou acesso a sistemas internos.

Modelo de relato: transforme texto em informação verificável

Um formulário estruturado reduz perguntas repetidas:

{
  "title": "Possível acesso entre organizações no endpoint de documentos",
  "asset": "API de homologação autorizada",
  "affected_version": "2026.10.1",
  "preconditions": [
    "Duas organizações de teste",
    "Usuário autenticado da organização A",
    "Documento sintético pertencente à organização B"
  ],
  "steps": [
    "Criar o documento na organização B",
    "Solicitar o documento com a sessão da organização A",
    "Registrar status HTTP e conteúdo sanitizado"
  ],
  "expected_result": "Acesso negado",
  "observed_result": "Documento sintético retornado",
  "claimed_impact": "Possível leitura entre organizações",
  "ai_assistance": {
    "used": true,
    "purpose": ["redação", "sugestão de teste"],
    "human_verified_steps": true
  },
  "evidence": [
    {
      "type": "sanitized_http_transcript",
      "attachment_id": "evidence-001"
    }
  ]
}

Esse é um contrato de aplicação proposto, não um padrão oficial.

Separe claimed_impact do impacto confirmado pela equipe. Valide tipos e comprimentos no backend e mantenha um canal para relatos que não se encaixem no formulário.

Exemplo do dia a dia: API com múltiplos clientes

Considere uma empresa fictícia com APIs em Kubernetes, PostgreSQL e workers de processamento.

Antes, todos os relatos viravam tickets de engenharia com a prioridade sugerida pelo remetente. Relatórios extensos consumiam horas, mesmo quando faltavam versão e pré-condições.

A empresa passa a aplicar três etapas:

1. Conferir escopo e informações disponíveis.
2. Identificar lacunas de evidência.
3. Encaminhar relatos verificáveis ao responsável técnico.

No exemplo do acesso entre organizações, a equipe reproduz o comportamento com duas contas sintéticas. Descobre que a consulta filtra o identificador do documento, mas não a organização vinculada à sessão.

A correção acrescenta a verificação de autorização e testes de regressão para acessos entre organizações.

O resultado esperado é uma investigação mais objetiva. A existência da vulnerabilidade foi estabelecida por comportamento observado; a IA ajudou a organizar o relato.

Esse cenário é didático e não representa um incidente ou resultado medido.

Laboratório em GKE: valide com isolamento

GKE Sandbox e Agent Sandbox

GKE Sandbox fornece isolamento adicional para workloads. A documentação permite solicitar o runtime gVisor por meio de runtimeClassName: gvisor. Já Agent Sandbox adiciona recursos próprios para gerenciar ambientes de agentes e possui um procedimento específico de habilitação.

O laboratório abaixo usa um Job Kubernetes com GKE Sandbox. Ele não instala o controlador Agent Sandbox nem implementa um ambiente completo de RL.

Para reproduções pontuais, essa abordagem reduz componentes operacionais. Ambientes persistentes de agentes podem justificar a adoção do controlador específico.

Pré-requisitos

Use um cluster de laboratório separado da produção, com:

• Pool compatível com gVisor.
• Implementação de rede que aplique NetworkPolicy.
• Imagens aprovadas e dados sintéticos.
• Identidades sem acesso aos projetos de produção.

Em um cluster GKE Standard existente, a documentação apresenta a criação de um pool com --sandbox=type=gvisor. Mantenha também um pool adequado aos componentes de sistema que não usam o sandbox.

gcloud container node-pools create disclosure-sandbox \
  --project=SEU_PROJETO \
  --cluster=SEU_CLUSTER \
  --location=SUA_REGIAO_OU_ZONA \
  --sandbox=type=gvisor

Adapte os identificadores. Esse comando cria infraestrutura faturável; sizing, autoscaling e identidade dos nós precisam ser definidos para o laboratório.

YAML completo para um teste controlado

apiVersion: v1
kind: Namespace
metadata:
  name: disclosure-lab
  labels:
    pod-security.kubernetes.io/enforce: restricted
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: reproduction-runner
  namespace: disclosure-lab
automountServiceAccountToken: false
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: disclosure-lab
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: approved-test
  namespace: disclosure-lab
data:
  test.py: |
    import json
    import sys

    # Teste sintético do pipeline, não reprodução de uma falha real.
    result = {
        "case_id": "LAB-001",
        "status": "completed",
        "synthetic_data": True
    }
    print(json.dumps(result), flush=True)
    sys.exit(0)
---
apiVersion: batch/v1
kind: Job
metadata:
  name: reproduction-lab-001
  namespace: disclosure-lab
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 120
  ttlSecondsAfterFinished: 600
  template:
    metadata:
      labels:
        app: reproduction-runner
    spec:
      runtimeClassName: gvisor
      serviceAccountName: reproduction-runner
      automountServiceAccountToken: false
      restartPolicy: Never
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: runner
          image: python:3.12-slim
          command:
            - python
            - -I
            - -B
            - /tests/test.py
          resources:
            requests:
              cpu: 250m
              memory: 128Mi
            limits:
              cpu: "1"
              memory: 256Mi
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          volumeMounts:
            - name: tests
              mountPath: /tests
              readOnly: true
            - name: temporary
              mountPath: /tmp
      volumes:
        - name: tests
          configMap:
            name: approved-test
        - name: temporary
          emptyDir:
            sizeLimit: 64Mi

O manifesto cria um namespace, uma identidade sem token automático, uma política de isolamento e um Job com tempo limitado. O script apenas valida a execução do pipeline.

Os campos principais são:

• runtimeClassName: solicita execução com gVisor.
• backoffLimit: 0: evita repetição automática do teste.
• activeDeadlineSeconds: limita a duração.
• ttlSecondsAfterFinished: permite limpeza do Job concluído.
• requests e limits: orientam agendamento e limitam recursos.
• securityContext: restringe privilégios e escrita.
• default-deny: isola entrada e saída dos Pods selecionados.

NetworkPolicies dependem do suporte da rede e suas permissões são aditivas: outra política pode autorizar tráfego. Elas não substituem todos os controles de rede e identidade.

Adapte nome do caso, recursos e script revisado. Em produção, fixe a imagem por digest aprovado, aplique quotas e exporte evidências antes da limpeza.

Para testar uma API, crie uma réplica sintética e permita somente o tráfego necessário. Não libere internet irrestrita para acomodar uma PoC.

Produção: disponibilidade sem ampliar permissões

O serviço de recebimento deve operar separadamente dos executores.

Mantenha múltiplas réplicas do portal, fila durável e armazenamento persistente de evidências. Workers precisam ser idempotentes: receber novamente a mesma mensagem não pode disparar testes duplicados.

Use filas distintas para análise textual e reprodução. Quando houver sinais de exploração ativa, encaminhe o caso à resposta a incidentes sem esperar o processamento comum.

Disponibilidade e confiança são problemas diferentes. Um portal pode ser altamente disponível e ainda encaminhar alegações incorretas. A validação técnica continua necessária.

Segurança do processo e da infraestrutura

Proteja o próprio triador

Um anexo pode tentar instruir o agente a acessar um endereço externo ou revelar informações internas.

Mantenha autorização e validação de ferramentas fora do modelo. A OWASP recomenda menor privilégio, tratamento de saídas como não confiáveis e controles específicos nas ações de ferramentas. Um prompt de proteção, isoladamente, não estabelece essa fronteira.

Aplique:

• RBAC — controle de acesso baseado em papéis — restrito por componente.
• ServiceAccounts diferentes para recebimento, análise e execução.
• IAM — gerenciamento de identidades e acessos — sem permissões de produção no laboratório.
• Secrets fora de prompts, anexos e ConfigMaps.
• Criptografia em trânsito e em repouso.
• Retenção e acesso auditável às evidências.

Não faça download automático de toda URL recebida. Isso pode expor serviços internos a Server-Side Request Forgery — SSRF. Valide destinos, redirecionamentos e endereços resolvidos.

Desenvolvimento x produção

Um namespace ajuda a organizar workloads, mas não constitui sozinho uma fronteira suficiente para executar código hostil.

Troubleshooting

O Job fica em Pending

Possíveis causas: runtime ausente, falta de capacidade, quotas ou restrições de agendamento.

kubectl get runtimeclass
kubectl get pods -n disclosure-lab
kubectl describe job reproduction-lab-001 -n disclosure-lab
kubectl get events -n disclosure-lab \
  --sort-by=.metadata.creationTimestamp

Leia os eventos antes de alterar recursos ou remover restrições.

O teste termina sem resultado

kubectl logs -n disclosure-lab \
  job/reproduction-lab-001

kubectl get job reproduction-lab-001 \
  -n disclosure-lab -o yaml

Investigue timeout, falha do script ou limite de memória. Erro de execução significa resultado inconclusivo, não relato inválido.

O teste não acessa a API sintética

kubectl get networkpolicy -n disclosure-lab -o yaml
kubectl get pods -n disclosure-lab --show-labels

Confira seletores, porta e permissões de entrada e saída. No exemplo, o bloqueio é intencional.

Relatos legítimos são encerrados incorretamente

Revise casos encerrados, motivos registrados e decisões após mudanças de modelo. Mantenha recurso humano e trate classificações automáticas como propostas.

Observabilidade

Use Prometheus para métricas, Grafana para painéis, Loki para logs sanitizados e OpenTelemetry para instrumentar o caminho entre portal, fila e workers.

Métricas úteis incluem:

• Volume por estado do relato.
• Idade do item mais antigo na fila.
• Tempo de confirmação de recebimento.
• Tempo até reprodução e correção.
• Execuções inconclusivas.
• Decisões automáticas revertidas por revisão.
• Custo por vulnerabilidade confirmada.

Nomes como disclosure_reports_total e disclosure_reproduction_duration_seconds são propostas de instrumentação, não métricas nativas.

Não use identificadores de relatos como labels do Prometheus: isso aumenta cardinalidade. Use correlação em logs e traces, sem registrar tokens, payloads sensíveis ou anexos completos.

Alerte por fila envelhecida, indisponibilidade do canal, falhas de persistência e aumento de decisões revertidas.

Custos e FinOps

O custo combina infraestrutura, consumo de modelos e tempo de especialistas.

Faça validações baratas antes das chamadas de IA. Use análise textual para organizar informações e reserve reprodução para casos que precisam dela.

Limite chamadas, tokens, execuções e duração por caso. Evite reenviar anexos inteiros em cada interação.

No Kubernetes, requests superdimensionados desperdiçam capacidade; memória insuficiente torna testes inconclusivos. Meça consumo real antes de ajustar.

Spot pode atender reproduções interrompíveis e idempotentes. Componentes de recebimento, fila e evidências exigem uma estratégia de disponibilidade apropriada, frequentemente com capacidade On-Demand.

A métrica central é o custo por descoberta validada, acompanhado da qualidade da triagem.

Onde RL pode contribuir

RL pode ser pesquisado em um ambiente separado para ensinar agentes a escolher entre solicitar complemento, recomendar reprodução ou encaminhar um relato.

Use casos históricos sanitizados, rótulos revisados e conjuntos separados de treinamento e avaliação. O agente não deve receber acesso aos ativos originais.

A recompensa precisa considerar precisão, custo de investigação e perda de vulnerabilidades reais. Recompensar apenas quantidade de encerramentos pode produzir um agente eficiente em descartar relatos.

Esse laboratório é pesquisa. Sua adoção operacional depende de avaliação e controles de execução.

Boas práticas e o que evitar

Padronize estados, responsáveis e motivos de decisão. Preserve evidências originais e registre separadamente interpretações humanas e automáticas.

Evite:

• Rejeitar relatos apenas porque usaram IA.
• Confundir tamanho do texto com evidência.
• Executar anexos diretamente no CI/CD — integração e entrega contínuas.
• Conceder cluster-admin ao triador.
• Considerar timeout uma prova de inexistência da falha.
• Publicar detalhes automaticamente.
• Prometer prazo de correção sem avaliar impacto e dependências.

Deduplicação deve sugerir relações entre casos e permitir revisão. Relatos parecidos podem envolver versões ou causas diferentes.

Quando utilizar e quando simplificar

O fluxo completo é indicado para organizações com múltiplos produtos, volume recorrente de relatos e necessidade de reprodução controlada.

Para uma equipe pequena, uma caixa monitorada, política pública, formulário simples e responsável definido podem ser suficientes.

Kubernetes se justifica quando a execução isolada precisa de escala e padronização. RL se justifica quando existe uma pergunta de pesquisa e dados adequados para avaliação.

Resumo prático

Antes de ampliar a automação:

• Publique escopo e canal de contato.
• Separe hipóteses de resultados observados.
• Exija evidências proporcionais ao caso.
• Restrinja modelos e ferramentas ao menor privilégio.
• Reproduza em ambiente autorizado e isolado.
• Preserve resultados inconclusivos.
• Revise decisões e coordene a comunicação.

Conclusão

Preparar a divulgação de vulnerabilidades para relatos assistidos por IA exige critérios claros de evidência e controle das ações que produzem efeitos.

A IA pode acelerar leitura, organização e comparação de relatos. Sandboxes podem tornar a reprodução mais controlada. A confirmação técnica, a correção e a comunicação continuam dependendo de responsáveis e decisões verificáveis.

Em uma estratégia de Platform Engineering, esse processo transforma relatos externos em trabalho rastreável: cada descoberta tem evidências, cada execução tem limites e cada publicação tem uma justificativa técnica.

Referências

• CERT Guide to Coordinated Vulnerability Disclosure
• RFC 9116 — security.txt
• OWASP — LLM Prompt Injection Prevention
• Google Cloud — GKE Sandbox
• Google Cloud — Enable Agent Sandbox on GKE
• Kubernetes — Network Policies