[PATCH 12/14] docs: security-bugs: explain why AI-found bugs are handled publicly

[Willy Tarreau <w@1wt.eu>]

Many reporters of bugs found using AI do not follow the instructions to
treat them as public, likely because they're worried to be blamed for
disclosing it.

The security team constantly receives duplicate reports within a very
short time, which makes it clear that when an LLM finds a bug, others
find it at the same time, and some may already be working on exploiting
it. Keeping it private then protects nobody, while handling it publicly
lets everyone fix it quickly without a needless embargo.

Let's clarify these points and also reword a sentence about AI reports
that could be read as "do not send them to us".

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 69dbc47f54625..72f9b8e45052e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -42,10 +42,16 @@ a system.
 **If you resorted to AI assistance to identify a bug, you must treat it as
 public**. While you may have valid reasons to believe it is not, the security
 team's experience shows that bugs discovered this way systematically surface
-simultaneously across multiple researchers, often on the same day. In this
-case, do not publicly share a reproducer, as this could cause unintended harm;
-just mention that one is available and maintainers might ask for it privately
-if they need it.
+simultaneously across multiple researchers, often on the same day. Others are
+then likely to be already working on exploiting the same bug, so keeping it
+private would protect nobody, while handling it publicly lets everyone fix it
+quickly without wasting time in a needless embargo. This applies even when the
+bug falls within the threat model: only the fix and its description are made
+public, and reporters following this procedure will never be blamed for it. In
+any case, do not publicly share a reproducer, as this could cause unintended
+harm; just mention that one is available and maintainers might ask for it
+privately if they need it, or better, send it upfront in a separate message to
+maintainers only.
 
 If you are unsure whether an issue qualifies, err on the side of reporting
 privately: the security team would rather triage a borderline report than miss
@@ -169,10 +175,10 @@ ignored.
 Use common sense when evaluating the report. If the affected file has not been
 touched for more than one year and is maintained by a single individual, it is
 likely that usage has declined and exposed users are virtually non-existent
-(e.g., drivers for very old hardware, obsolete filesystems). In such cases,
-there is no need to consume a maintainer's time with an unimportant report. If
-the issue is clearly trivial and publicly discoverable, you should report it
-directly to the public mailing lists, without the reproducer.
+(e.g., drivers for very old hardware, obsolete filesystems). In such cases, as
+well as when the issue is clearly trivial and publicly discoverable, there is
+no need to consume a maintainer's time with a private security report: just
+send the fix publicly like any regular bug fix, without the reproducer.
 
 At the very least, when using an AI assistant to find and report bugs, make the
 assistant read this file and threat-model.rst before proceeding, and have it
-- 
2.52.0