[MAINTAINERS SUMMIT] Scaling our security process

[Sasha Levin <sashal@kernel.org>]

Hi folks,

As everyone might have noticed by now, LLMs are finding real, exploitable bugs
at a growing rate, and the same tools are available to people who won't report
what they find. At the same time we're getting a stream of plausible looking AI
slop that wastes reviewer time.

Clearly this is not kernel-specific, but given where the kernel sits in the
stack this creates more of a problem for us. We spent decades saying security
by obscurity doesn't work and that being open makes us more secure. In practice
we leaned a bit on a version of it anyway: security by complexity. The code was
public, but it was complicated enough, and there was so much of it, that
finding a serious bug took rare skills and a lot of time. AI removes that
barrier. What's left is how fast we triage, fix, and ship.

With that in mind, I'd like to discuss:

1. Does security@ still work? It was built for a handful of carefully written
reports, handled start to finish by a small group of volunteers. That process
never really scaled before, and it won't scale now. Does it make sense to
separate the roles? let AI driven tooling handle intake, filtering, and
reproduction, and keep the humans for developing and coordinating fixes for
reports that survive triage?

2. Where does stable@ fit? Landing a fix upstream and calling it a day helps
nobody. Our users don't run mainline; they benefit when the fix shows up in the
kernel they actually run. Today a fix that goes through security@ often lands
in Linus's tree with no stable tag and no backport, sometimes not even to
recent LTS trees. If a security fix isn't in the LTS trees, is the bug actually
fixed? And should folks who care about these backports be in the loop while the
fix is being developed instead of finding out after the fact?

3. Do we want some sort of a shared distro security backport list? Every major
distro pays people to backport security fixes, and they all do the same work in
parallel behind separate walls. A list where upstream and distro security teams
write and review backports together, would pool that effort and land fixes
where users are. Sure, it allows for more leaks, but we end up causing these
leaks ourselves when we release a fix without working backports.

4. How can CVE tracking better serve our users? We assign a lot of CVEs, and
the common complaint is that consumers can't tell which ones matter for the
kernel they actually run. The CVE program's SADP pilot points at one answer:
downstream suppliers attach "affected / not affected / fixed in X" status
directly to upstream CVE records. Do we want to push the ecosystem in that
direction, and what should the kernel CNA provide to make it easy?

5. Do we need a policy on AI generated reports and patches? Other projects have
one. Can we tell AI assisted quality work from slop without burning out the
people doing triage?


I'd really want to steer away from the "AI is good/evil" discussion, and just
focus on the reality we have all seen through the past year or so.

-- 
Thanks,
Sasha