[MAINTAINERS SUMMIT] Scaling our security process

[MAINTAINERS SUMMIT] Scaling our security process

[Sasha Levin]

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

Re: [MAINTAINERS SUMMIT] Scaling our security process

[Greg KH]

One comment about something I've been working on lately:

On Tue, Jul 14, 2026 at 07:54:58PM -0400, Sasha Levin wrote:
> 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?

It was not really "built" for anything other than a place that people
could report security bugs and get them fixed.  We have changed the way
it works over the past months, and for right now, things seem _MUCH_
smoother than ever before.

Also, we are getting funding "any day now" to have someone work full
time on this, to be the "point person" for the alias to help when things
fall through the cracks, as sometimes happens.  We have verbal
guarantees of at least 6 months funding, and if that goes well, it
should be extended.

LLMs really can't be used for security@ EXCEPT if you use a local model,
due to the "interesting" legal rules that security@ has to operate
under.  We've been using it there for a while now, when needed, and it
has helped to spit out "first cut" patches for reports that do not
contain a patch to start with.  That usage is gone way down now that we
ask for a patch in the intial report as all of these reports are being
generated by a LLM anyway.

And attempting to use a LLM to handle intake and filtering just doesn't
work.  Many people who have experience with being on the recieving end
of such a feed have agreed, that isn't the real problem with getting
this feed at all.  The real problem is unresponsive reporters, and
"middlemen" that like to put their company inbetween the reporter of the
bug, and us, the fixer of the bug.  A LLM just can't do anything there,
but I'll let the person who ends up doing the work for this for the next
6 months have their say after they've been on the recieving end of the
firehose for a while :)

thanks,

greg k-h