No início de outubro de 2026, engenheiros da Amazon Web Services (AWS) apresentaram um fluxo de triagem de CVEs, registros de vulnerabilidades identificadas por CVE, para o kernel Linux mantido na infraestrutura do Amazon EC2. Um script filtra os casos aplicáveis, um agente de IA classifica os restantes e engenheiros revisam o resultado. Esse kernel é diferente do Amazon Linux e dos kernels executados nas máquinas virtuais dos clientes.
Como a AWS filtra e classifica CVEs
O primeiro filtro compara as versões afetadas e os arquivos citados em cada CVE com a versão do kernel e os arquivos compilados na imagem da AWS. Essa etapa usa um script, sem IA. Nos slides da apresentação, a AWS informa que o filtro elimina cerca de 70% dos CVEs em seu ambiente; a proporção depende da configuração e do ambiente.
Os casos restantes seguem para o agente, que recebe a árvore de código do kernel, as configurações, um modelo de ameaças e critérios de gravidade. Ele produz uma tabela com uma linha por CVE, incluindo subsistema, tipo de vulnerabilidade e vetor de ataque.
A IA classifica; engenheiros revisam
O agente não aplica correções. Depois da classificação, engenheiros analisam a tabela e decidem como tratar cada caso. Segundo o relato da apresentação, dois engenheiros costumam fazer essa revisão, apontada como a etapa mais lenta do fluxo.
A AWS informou que o agente processa cada CVE em cerca de 3,4 segundos, ante minutos de triagem humana por caso. Esse número mede o processamento da triagem pelo agente; não inclui revisão, correção, testes ou implantação. Justinien Bouron estimou informalmente que 5% a 10% das decisões do agente eram problemáticas.
Atualizar o kernel também exige trabalho fora dele
Na atualização do Linux 5.10 para o 6.12, a AWS distribuiu os problemas acompanhados entre quatro áreas. As porcentagens se referem a esses problemas, não a CVEs nem ao tempo gasto em correções.
| Área em que os problemas foram resolvidos | Parcela dos problemas acompanhados |
| Espaço do kernel | 45% |
| Espaço do usuário | 43% |
| Configuração do kernel | 7% |
| Firmware ou hardware | 5% |
A AWS informou separadamente que 15% das correções feitas no espaço do kernel foram integradas ao projeto principal, ou upstream. Os exemplos da apresentação mostram o alcance dos testes de compatibilidade: uma mudança no armazenamento de áreas de memória virtual tornou mmap() e munmap() mais lentos; uma alteração no escalonador mudou o tempo de execução de fork(); e um aumento no tamanho máximo padrão de requisições da camada de blocos provocou timeouts de I/O no firmware, tratados com ajustes de sysctl.
A equipe também relatou que levou 24 meses para atualizar da versão 4.19 para a 5.10, 12 meses da 5.10 para a 6.12 e seis meses da 6.12 para a 6.18. A AWS atribuiu a redução desses prazos a ferramentas melhores, maior cobertura de testes e experiência da equipe.
O que mostram os números dos ramos LTS
LTS significa suporte de longo prazo. Em 16 de setembro de 2026, a fotografia apresentada pela AWS contabilizava CVEs sem correção em oito ramos LTS do Linux. Para os seis ramos mais recentes da lista, os slides também informavam a mediana de dias entre a integração de uma correção ao ramo principal e sua publicação no ramo LTS.
| Ramo LTS do Linux | CVEs sem correção em 16 de setembro de 2026 | Mediana entre correção no ramo principal e publicação no LTS (dias) |
| 5.10 | 1.709 | 31,8 |
| 5.15 | 1.567 | 31,5 |
| 6.1 | 1.062 | 28,8 |
| 6.6 | 762 | 23,1 |
| 6.12 | 483 | 19,0 |
| 6.18 | 229 | 18,1 |
Na mesma fotografia, o ramo 4.19 tinha 3.725 CVEs sem correção e o 5.4, 3.481. Esses totais dizem respeito a cada ramo Linux; não indicam quantas vulnerabilidades afetam o kernel implantado pela AWS no EC2. Da mesma forma, as medianas medem o intervalo até a publicação em um ramo LTS, não o tempo de implantação da AWS.
Quando a triagem identifica um CVE relevante, a apresentação da AWS descreve quatro respostas possíveis, escolhidas conforme o caso: não agir se a vulnerabilidade não afetar o ambiente; esperar o próximo pacote LTS quando o impacto permitir; selecionar e aplicar uma correção específica quando for preciso agir mais rápido; ou usar uma solução alternativa quando não for possível atualizar o kernel. A AWS classifica essas opções por velocidade relativa e risco, não como medidas universais.
Em 27 de outubro de 2026, as ferramentas descritas ainda não haviam sido lançadas. Dylan Johnson disse que a equipe gostaria de explorar a possibilidade de compartilhar o filtro.
