AWS usa agente de IA para triar CVEs do kernel Linux que sustenta a EC2

Um problema que cresceu de 2 para 16 CVEs por dia

Em palestra no início de outubro de 2026 na Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → Plumbers Conference, em Praga, os engenheiros da AWS Dylan Johnson e Justinien Bouron detalharam como o time que mantém o kernel Linux usado na infraestrutura da EC2 decide quais vulnerabilidades importam. É um kernel diferente do Amazon Linux e dos kernels que o cliente roda dentro da própria instância: é o que sustenta a camada de virtualização da AWS por baixo das cargas de trabalho.

O volume de CVEs do kernel Linux mudou de patamar depois que o projeto virou uma CVE Numbering Authority (CNA) em fevereiro de 2024, passando a publicar seus próprios identificadores em vez de depender de terceiros. Antes disso, a AWS via cerca de 2 CVEs de kernel por semana. Depois, o ritmo subiu para cerca de 16 por dia, com um pico de 848 CVEs publicados em 15 de agosto de 2026. A própria documentação de CVEs do kernel reconhece que o projeto não sabe como cada sistema usa o código, então cabe a cada usuário decidir o que se aplica a ele.

O pipeline: filtro, agente, revisão humana

O processo da AWS tem três estágios, e só o do meio usa IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →:

1. Filtro automático (sem IA). Um script lê o registro JSON de cada CVE, compara a versão afetada e os arquivos-fonte listados com a configuração real do kernel da AWS e descarta o que não se aplica. Bouron disse que isso elimina cerca de 70% dos CVEs recebidos, mas fez questão de avisar que o percentual depende muito de como o kernel está configurado em cada ambiente.
2. Agente de IA. O que sobra vai para um agente que recebe a árvore de código-fonte do kernel da AWS, a configuração de cada plataforma, uma descrição do ambiente e do modelo de ameaças, e uma régua de severidade própria. Ele devolve uma tabela com subsistema afetado, tipo de vulnerabilidade e vetor de ataque. O time ignora deliberadamente o CVSS, porque o escore padrão não é específico do ambiente da AWS.
3. Revisão humana. Dois engenheiros normalmente revisam a tabela produzida pelo agente antes de qualquer decisão virar ação.

A diferença de velocidade entre máquina e humano é o dado que mais chama atenção nos slides: o agente leva cerca de 3,4 segundos por CVE, contra minutos de trabalho humano. Bouron afirmou que a revisão manual hoje é a etapa mais lenta do pipeline, e que o time não pretende eliminá-la.

"Um classificador bem chique", não um juiz

Johnson resumiu o papel do agente de forma direta:

Estamos realmente usando isso como um classificador bem chique.

We're really using it as a very fancy classifier.Dylan Johnson, engenheiro da AWS

Bouron foi além ao explicar por que a revisão humana continua obrigatória:

Não queremos que nossa postura de segurança inteira dependa do resultado de um agente de LLM.

We don't want to hinge our entire security posture on the output of an LLM agent.Justinien Bouron, engenheiro da AWS

Quando perguntado sobre a precisão do agente, Bouron estimou, sem apresentar uma avaliação formal, que entre 5% e 10% das decisões do agente eram problemáticas. É uma margem de erro relevante para quem decide quais vulnerabilidades no kernel de uma das maiores nuvens públicas do mundo merecem ação imediata, e é exatamente por isso que o time manteve humanos na malha, mesmo com o ganho de velocidade.

Desligar recursos do kernel para reduzir a superfície

Além de filtrar e classificar CVEs, a AWS também desliga ativamente recursos do kernel que não usa, reduzindo quantos CVEs sequer se aplicam ao seu ambiente. Bouron descreveu essa abordagem como "enganosamente difícil": os slides listam mais de 32.000 opções de configuração, e desativar a opção errada pode gerar bugs ou regressões de performance que só aparecem meses depois. É uma vantagem que a AWS tem por controlar um ambiente interno fechado, algo que Johnson reconheceu ser mais difícil de replicar numa distribuição de propósito geral.

Por que a AWS quer migrar para LTS mais novos

Os dados apresentados reforçam o argumento do time para acelerar a adoção de branches LTS (long-term support) mais recentes. Para CVEs que afetam as seis branches estudadas, o tempo mediano entre a correção no mainline e a chegada da correção no release LTS foi de 31,8 dias no Linux 5.10 e de 18,1 dias no 6.18. Em 16 de setembro de 2026, havia 1.709 CVEs conhecidos sem correção na branch 5.10, contra 229 na 6.18. São contagens por branch, e não indicam quantos desses CVEs de fato afetam o kernel específico da AWS.

Fazer o próprio backport de correções também tem risco embutido: Bouron apontou que os registros de CVE costumam citar apenas o commit final que corrigiu o bug, sem listar commits pré-requisito. Um time que aplica só o commit indicado pode continuar vulnerável mesmo depois do patch.

A AWS tem encurtado o próprio ciclo de migração entre versões de kernel:

Durante a migração de 5.10 para 6.12, 43% dos problemas rastreados foram resolvidos em userspace, quando cargas de trabalho dependiam de um comportamento antigo do kernel. Johnson disse que o time agora vai rodar kernels estáveis em ambiente de teste continuamente ao longo do ano, migrando a frota assim que cada novo LTS sair.

O que outras empresas estão fazendo

A Microsoft apresentou, na mesma conferência, um pipeline parecido para o Azure Linux: o veredito de triagem vem de uma tabela de regras, e a IA só sugere entradas para essa tabela. O time do Azure também usa agentes para backporting e relatou que um loop de build-and-test elevou a taxa de sucesso dessa tarefa de cerca de 50% para 80%.

Já o CodeMender, do Google DeepMind (coberto pelo InfoQ em outubro de 2025), foca em escrever as correções em si, não em triar CVEs. Segundo o anúncio do projeto, pesquisadores humanos revisam todo patch antes de ele seguir para o upstream. São três respostas diferentes ao mesmo problema: volume de CVEs crescendo mais rápido do que times humanos conseguem revisar sozinhos.

O que fica em aberto

A AWS não abriu o código das ferramentas. Perguntado sobre isso, Johnson disse que o time gostaria de explorar a possibilidade de compartilhar a ferramenta de filtro, a parte sem IA do pipeline, mas não deu prazo nem compromisso. Berend de Boer, CTO da Process Focus, comentou no LinkedIn sobre o tamanho do trabalho envolvido em manter esse tipo de infraestrutura:

Foque no que torna o seu negócio valioso para os seus clientes.

Focus on what makes your business valuable to your customers.Berend de Boer, CTO da Process Focus

Para quem opera workloads em EC2, o pipeline descrito não é algo que o cliente configura ou vê rodando: é a AWS cuidando da camada que fica abaixo da instância. Mas o desenho importa como referência prática para qualquer time que hoje recebe uma enxurrada de CVEs e tenta decidir o que de fato se aplica ao seu ambiente: a lição da AWS é usar IA para classificar em escala, manter revisão humana no que decide ação, e não terceirizar a decisão final para o modelo.

Fonte: InfoQ