Triagem de CVEs com IA: descarte por evidência antes de chamar o modelo
O fluxo apresentado pela AWS separa filtro determinístico, análise por agente e decisão humana. A fronteira entre eles importa.
A equipe responsável pelo kernel da infraestrutura EC2 apresentou uma triagem de CVEs que combina filtro convencional, análise por agente e revisão humana.[6] No ambiente descrito, o filtro elimina cerca de 70% dos casos antes de qualquer chamada ao modelo, verificando incompatibilidade com a versão ou com os arquivos efetivamente compilados.[6] O ganho mais interessante começa antes da IA.
O que muda para quem desenvolve
O agente recebe código-fonte, configuração, modelo de ameaças e critérios de severidade; sua classificação é depois revisada, geralmente por dois engenheiros.[6] O desenho não apresenta a saída do modelo como decisão final.
A leitura de engenharia é separar três perguntas: o componente afetado existe, o caminho vulnerável pode ser relevante e qual ação deve ser tomada. A primeira deveria aproveitar evidências estruturadas sempre que possível. A segunda pode exigir investigação. A terceira envolve responsabilidade sobre risco e prazo. Misturá-las em um único prompt torna difícil saber por que um alerta foi ignorado.
O escopo relatado é o kernel da própria infraestrutura EC2, não automaticamente o Amazon Linux nem as máquinas virtuais dos clientes.[6] Não use o percentual de descarte desse ambiente como expectativa para uma aplicação web ou para outro inventário.
Como aplicar
Em um protótipo de triagem de dependências, comece por uma tabela rastreável: boletim, componente instalado, versão observada, configuração relevante, conclusão e evidência. Diferencie ausência comprovada de informação ainda não obtida. Um campo vazio não deveria virar um descarte automático.
Depois, entregue ao modelo somente os casos que precisam de análise contextual. Peça referências aos trechos de código e de configuração que sustentam a recomendação. Se a evidência não estiver disponível, a saída deve permanecer inconclusiva, em vez de receber uma justificativa plausível.
Para avaliar o protótipo, use um conjunto fechado de alertas já revisados por pessoas. Inclua casos aplicáveis, não aplicáveis e ambíguos. Compare especialmente os falsos descartes, registre divergências e mantenha aprovação humana para encerramento. Meça também o tempo de revisão: produzir pareceres rapidamente não adianta se cada um exigir reconstruir toda a investigação.
Cuidados e limites
O tempo informado foi de aproximadamente 3,4 segundos por CVE, mas os apresentadores estimaram informalmente problemas em 5% a 10% das decisões, sem avaliação formal de precisão.[6] Não transforme esses valores em garantia de desempenho ou taxa de erro para outro projeto.
A apresentação também alerta para kernels LTS antigos e para correções que dependem de commits anteriores; as ferramentas mostradas ainda não haviam sido publicadas.[6] Portanto, a oportunidade imediata é aproveitar o padrão de desenho, não prometer instalar uma solução pronta. Automatize a reunião de evidências sem automatizar o esquecimento do risco.
Fonte
[6] Fonte: InfoQ