Re: [MAINTAINERS SUMMIT] Scaling our security process

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?

>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?

-- 
Thanks,
Sasha