From: Greg KH <greg@kroah.com>
To: Sasha Levin <sashal@kernel.org>
Cc: ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Scaling our security process
Date: Wed, 15 Jul 2026 06:43:04 +0200 [thread overview]
Message-ID: <2026071553-tuition-hatchery-4588@gregkh> (raw)
In-Reply-To: <albMUqack9yMq0rF@laps>
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
prev parent reply other threads:[~2026-07-15 4:43 UTC|newest]
Thread overview: 2+ 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 [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=2026071553-tuition-hatchery-4588@gregkh \
--to=greg@kroah.com \
--cc=ksummit@lists.linux.dev \
--cc=sashal@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.