From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 029B932B11D for ; Thu, 16 Jul 2026 15:17:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784215044; cv=none; b=spt2G15LpefkPv5mhiVsY1IqdPoAB3u3mC92UnfUqj4PQ37CU6sJ5Wji/T7D14gwf7ZM1U16NsFX1cr4ahFIDI09I7cZxIJvNMzFYWVKXwQsW/iTjlhaBl7WnPNui8FXj4fJss1apk0yKyVK0ikwUMMv3xy4tkbYyektD3AUO7U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784215044; c=relaxed/simple; bh=2l3GxBRU1SFghrMkZSysxeifIg4XbuZeIG4C5mqbDps=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hInX76yJDsZYXlR3XyuceLwUkpbgH6gZXW4dgCnO7a+xVizKPozhT/srIckQryeEayMog4+hgtc+1hqbnnOV7PMvl61KFFoI0iKOF8f2eD1y38Juv2VekIMZ5bRucZZk+znVhV2Pl+5wiQkowFob2/2TBRP++SfeKpGmbPF08UQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=haoGn6U/; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="haoGn6U/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97BA41F00AC4; Thu, 16 Jul 2026 15:17:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784215042; bh=FY1byJB/g3eNWnujM5svpLKcv6p3D00AJvzHmJvzukM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=haoGn6U/IeG4sv3hN/grN6HwR732etAvhFo6xL3/GVVWd3psmKmMiPXbUSpye7XZv VEl6fpw+HMgZImslArEJdJxZIp0KeRge2YCi6t8y3Ckox29TUUa4iR+G6CXurwOYfu RAcpTrGryTw/2Jpx/kybaVkiZEV75/xmWWmg+dRIq8R/1E97fZjr+1xEoxFgSAfIn5 7GgOFrnC/Eqvr+fR+/Vpm2tLsjZTpqO0cWd2CSaJfRQq7gcdiKDybYeRx9nxF5Icu1 3tYmeYVs4kvIIrOeB0zIbXW5Hy1YOpwgye0/lQtwBPms8GjyxRwXPfNMmwUjuGBHwA BTkioUBLJCCIg== Date: Thu, 16 Jul 2026 11:17:21 -0400 From: Sasha Levin To: Greg KH Cc: ksummit@lists.linux.dev Subject: Re: [MAINTAINERS SUMMIT] Scaling our security process Message-ID: References: <2026071553-tuition-hatchery-4588@gregkh> Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline 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