[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <afI79Ruw_74rdrxq@yuggoth.org>
Date: Wed, 29 Apr 2026 17:12:21 +0000
From: Jeremy Stanley <fungi@...goth.org>
To: oss-security@...ts.openwall.com
Subject: Re: Coordinated Disclosure in the LLM Age
On 2026-04-29 00:29:35 -0400 (-0400), Lucas Holt wrote:
[...]
>At a minimum, if you're going to go public, use your AI to include
>a possible patch too. Don't just drop work on a random person
>because you got to find it first. That's not cool.
While I agree with this (and your earlier points), I was coming at
the question from my perspective as an upstream maintainer and
vulnerability coordinator of large/popular projects receiving these
reports. We operate under a 90-day maximum embargo already, but:
1. our processes are bursting at the seams under the current flood
of reports, and trying to manage them all in private is leading
to more accidents breaking our embargoes before things are ready
or distros/deployers have been given sufficient advance warning
2. in order to deal with the increased volume of reports, developers
are turning to public LLM services easing their burden even
though the reports are still under embargo
3. switching reports to public immediately on receipt allows us to
crowdsource help from a broader swath of our community rather
than relying solely on overwhelmed vulnerability coordinators and
security-focused maintainers
So yes, we *could* choose to switch reports to public immediately in
cases where we expect that others are finding the same bugs with the
same LLM service and just not telling us, or where developing a fix
without assistance from an LLM in sufficient time is too burdensome
on maintainers (many of our maintainers have become so reliant on
"LLM assistance" that they are resistant to being told they can't
use those for fixing embargoed vulnerabilities).
In addition to the great replies on this thread (thanks everyone!),
I also received a few bits of feedback from other colleagues in
favor of the status quo:
A. Some "enterprise" LLM license agreements claim the LLM operator
will prevent the LLM "learning" details from the user's prompts or
its own responses, or will guarantee knowledge the LLM acquires in
one customer's context won't bleed over into another customer's
context. (Whether you believe them or think they're competent enough
to do it correctly is another matter, of course.)
B. The timeframe for newly acquired data making it into the model in
these public LLMs is on the order of 6 months currently, so far
longer than our maximum embargo at the moment. (Not that I trust
it's the same for all LLM services, or will remain that slow in the
future.)
C. Public LLM services are slow and expensive, so claiming someone
else can trivially find the same vulnerability using the same LLM is
equivalent to saying that with enough time and money someone else
can find any vulnerability.
Anyway, for now I suppose I'll continue reminding my colleagues to
avoid keeping things under embargo unless necessary, and be careful
with their use of public/shared LLM services when writing advisories
or developing fixes under embargo. Thanks again to everyone who
weighed in!
--
Jeremy Stanley
Download attachment "signature.asc" of type "application/pgp-signature" (964 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
