Re: [MAINTAINERS SUMMIT] Scaling our security process
Greg KH <[email protected]> Wed, 15 Jul 2026 06:43:04 +0200
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <2026071553-tuition-hatchery-4588@gregkh> |
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