Engenheiros da Amazon Web Services apresentaram na Linux Plumbers Conference em Praga o processo que a empresa utiliza para gerenciar vulnerabilidades (CVEs) no kernel Linux mantido para infraestrutura EC2. O sistema combina filtro automatizado, agente de inteligência artificial e revisão humana em três etapas distintas.
O kernel gerenciado pela AWS para EC2 é mantido separadamente do Amazon Linux e dos kernels executados pelos clientes em máquinas virtuais. Desde que o projeto Linux tornou-se CVE Numbering Authority em fevereiro de 2024, o volume de vulnerabilidades disparou. Antes dessa data, a equipe recebia aproximadamente 2 CVEs de kernel por semana. Após o reconhecimento, o número aumentou para 16 por dia, com 848 vulnerabilidades publicadas em 15 de agosto de 2026.
/filters:no_upscale()/news/2026/10/aws-ai-agents-linux-kernel-cves/en/resources/1Screenshot%20From%202026-10-26%2016-05-38-1793031815876.png)
Imagem: InfoQ. Apresentação sobre processo de triagem de CVEs em infraestrutura EC2
Primeira etapa: filtro automatizado
O processo inicial não utiliza IA. Um script analisa registros de CVE em formato JSON para descartar vulnerabilidades cuja versão de kernel está fora do intervalo afetado ou cujos arquivos listados não são compilados na imagem. Essa etapa remove aproximadamente 70% das CVEs no ambiente AWS, embora o percentual dependa significativamente da configuração do kernel.
Segunda etapa: agente de IA
As vulnerabilidades restantes são encaminhadas a um agente de IA que recebe a árvore de código-fonte do kernel AWS, configurações de cada plataforma, descrição do ambiente, modelo de ameaça e rubrica de severidade. O agente produz uma tabela contendo o subsistema afetado, tipo de vulnerabilidade e vetor de ataque. A AWS deliberadamente ignora pontuações CVSS por não serem específicas a seu ambiente.
Conforme explicado por Dylan Johnson, o agente funciona como "um classificador muito sofisticado". Ele processa cada CVE em aproximadamente 3,4 segundos, comparado aos minutos que um engenheiro levaria. Uma estimativa informal, não acompanhada de avaliação formal, sugere que entre 5% e 10% das decisões do agente apresentam problemas.
Terceira etapa: revisão humana
Dois engenheiros normalmente revisam a tabela gerada pelo agente. A AWS mantém essa camada de revisão como crítica para sua postura de segurança. Justinien Bouron afirmou que "não queremos colocar toda nossa postura de segurança na saída de um agente LLM". A revisão humana atualmente representa o passo mais lento do processo, e a equipe não pretende removê-la.
Redução de superfície de ataque
A equipe desabilitou recursos de kernel desnecessários para reduzir o número de CVEs aplicáveis. Bouron descreveu essa abordagem como "enganosamente difícil". Mais de 32 mil opções de configuração de kernel existem, e remover a configuração incorreta pode causar bugs ou regressões de performance que aparecem meses depois.
Desafios com branches LTS antigas
Os dados da AWS demonstram que branches LTS mais antigas recebem correções posteriormente e carregam mais CVEs não corrigidas. Para vulnerabilidades afetando todos os seis branches estudados, a mediana de tempo da correção em mainline até um release LTS foi 31,8 dias para Linux 5.10 e 18,1 dias para 6.18. Em 16 de setembro, 1.709 CVEs conhecidas permaneciam não corrigidas em 5.10, comparado a 229 em 6.18.
Backporting manual de correções apresenta riscos adicionais. Registros de CVE frequentemente nomeiam apenas o commit final que resolveu a vulnerabilidade, não os commits de pré-requisito. Uma equipe que ignora essas dependências pode permanecer vulnerável após aplicar a correção listada.
Aceleração de upgrades
A AWS acelerou significativamente seus ciclos de atualização de kernel. A migração de 4.19 para 5.10 levou aproximadamente 2 anos desde o início do porte até deployment em produção. O upgrade seguinte consumiu cerca de 1 ano, enquanto a mudança para 6.18 levou 6 meses. Durante o upgrade de 5.10 para 6.12, 43% dos problemas rastreados foram resolvidos em userspace, onde workloads dependiam de comportamentos mais antigos do kernel.
Dylan Johnson indicou que a AWS agora executará kernels estáveis em testes durante o ano e migrará sua frota quando cada novo release LTS for lançado.
Contexto com outras abordagens
O time do Azure Linux da Microsoft apresentou um pipeline similar na mesma conferência. Sua abordagem utiliza uma tabela de regras para verdicts de triagem, com IA sugerindo inputs. O Azure emprega agentes para backporting e reportou elevação da taxa de sucesso de aproximadamente 50% para 80% usando feedback de build-and-test.
Google DeepMind's CodeMender, coberto pelo InfoQ em outubro de 2025, concentra-se em escrever correções, com revisão de pesquisadores humanos antes de cada submissão upstream.
Perspectiva sobre infraestrutura cloud
Berent de Boer, CTO da Process Focus, comentou no LinkedIn sobre o trabalho envolvido na execução de infraestrutura cloud. Ele listou host patching e CVEs do Linux entre os trabalhos que organizações assumem ao construir sua própria nuvem, recomendando: "Foque no que torna seu negócio valioso para seus clientes".
Publicação de ferramentas
A AWS não lançou publicamente as ferramentas de triagem. Quando questionado sobre código aberto, Dylan Johnson indicou interesse em explorar a possibilidade de compartilhar a ferramenta de filtro. A empresa reconheceu que seus usuários internos facilitam a desabilitação de features em comparação com uma distribuição de propósito geral.
