From: Sasha Levin <sashal@kernel.org>
To: Greg KH <greg@kroah.com>
Cc: ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Scaling our security process
Date: Thu, 16 Jul 2026 11:17:21 -0400 [thread overview]
Message-ID: <alj2AX17zXFMIjZW@laps> (raw)
In-Reply-To: <2026071553-tuition-hatchery-4588@gregkh>
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
prev parent reply other threads:[~2026-07-16 15:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 23:54 [MAINTAINERS SUMMIT] Scaling our security process Sasha Levin
2026-07-15 4:43 ` Greg KH
2026-07-16 15:17 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alj2AX17zXFMIjZW@laps \
--to=sashal@kernel.org \
--cc=greg@kroah.com \
--cc=ksummit@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox