Linux Kernel Summit discussions
 help / color / mirror / Atom feed
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

      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