Re: [MAINTAINERS SUMMIT] Scaling our security process

On Thu, Jul 16, 2026 at 11:17:21AM -0400, Sasha Levin wrote:
> On Wed, Jul 15, 2026 at 06:43:04AM +0200, Greg KH wrote:
> > 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.
> 
> It almost sounds like we need a CRM system here rather than a person?

Hah, no, any single-point-of-failure here would not be a good thing.

> > 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 :)
> 
> Ignoring the LLM for a moment, is there value in jumping through all these
> hoops if we don't also end up with backports of the issues that are being
> fixed?

I understand your worry here, but that's a separate issue.  First we
need to make sure the patches hit Linus's tree, which is what
[email protected] is for.  Then we need to make sure the patches hit stable
kernels, which is what stable@vger is for.  Two different groups/goals.

thanks,

greg k-h