According to Johnson and Bouron, the team saw about two kernel CVEs per week before 2024 and about 16 per day afterward, with 848 published on 15 August 2026. The kernel CVE documentation notes that the project cannot know how a given system uses the kernel, so users must decide which CVEs apply to them.
The first stage of AWS's process is a non-AI filter. Bouron explained that kernel CVE records are published in JSON listing affected versions and source files. A script discards a CVE if the kernel version is outside the affected range or if none of the listed files are built into the image. In AWS's environment, this removes about 70% of CVEs, though Bouron noted the figure depends heavily on kernel configuration.
Remaining CVEs go to an AI agent, which receives AWS's kernel source tree, configuration for each platform, a description of the environment and threat model, and a severity rubric. The agent produces a table recording the affected subsystem, vulnerability type, and attack vector. Bouron said the team ignores CVSS scores because they are not specific to its environment.
"We're really using it as a very fancy classifier," Johnson said.
Two engineers usually review the table. According to slides, the agent takes about 3.4 seconds per CVE, compared with minutes for a person. Bouron said review is now the slowest step and the team does not intend to remove it. "We don't want to hinge our entire security posture on the output of an LLM agent," he said.
When asked about accuracy, Bouron estimated that between 5% and 10% of the agent's decisions were problematic. He described this as an informal estimate, and the talk did not describe a formal evaluation.
The team also disabled kernel features it did not need to reduce the number of applicable CVEs. Bouron called this approach "deceptively difficult," noting the slides list more than 32,000 configuration options and that removing the wrong one can cause bugs or performance regressions appearing months later.
Data from the team shows older long-term-support (LTS) branches receive fixes later and carry more unfixed CVEs. For branches studied, the median time from a mainline fix to an LTS release was 31.8 days for Linux 5.10 and 18.1 days for 6.18. On 16 September, 1,709 known CVEs were unfixed in 5.10 compared with 229 in 6.18. Johnson said the move from 4.19 to 5.10 took about two years from starting porting work to full deployment, while the move to 6.18 took about six months. The team will now run stable kernels in testing through the year and move the fleet when each new LTS release appears.
Microsoft's Azure Linux team described a similar pipeline at the same conference, with triage from a rule table and AI only suggesting inputs. Google DeepMind's CodeMender, focused on writing fixes, was also noted by InfoQ as having human researchers review every patch.
AWS has not released the tools. When asked about open-sourcing, Johnson said the team would like to explore sharing the filtering tool. He also acknowledged that AWS's internal users make it easier to disable features than it would be for a general-purpose distribution.