[PATCH v2 3/3] security-team: Add section on multi-project embargoes

[Paul Barker <paul@pbarker.dev>]

This text is migrated from the Security private reporting wiki page [1],
originally written by Marta.

[1]: https://wiki.yoctoproject.org/wiki/index.php?title=Security_private_reporting&type=revision&diff=86034&oldid=86033

Cc: Marta Rybczynska <marta.rybczynska@ygreky.com>
Signed-off-by: Paul Barker <paul@pbarker.dev>
---
 documentation/security-reference/security-team.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/documentation/security-reference/security-team.rst b/documentation/security-reference/security-team.rst
index c83ada17eb56..169d503e94af 100644
--- a/documentation/security-reference/security-team.rst
+++ b/documentation/security-reference/security-team.rst
@@ -80,6 +80,28 @@ vulnerability as quickly as possible.
 The Yocto Project Security team adheres to the 90 days disclosure policy
 by default. An increase of the embargo time is possible when necessary.
 
+Handling multi-project embargoes
+--------------------------------
+
+In rare cases, a severe security issue affects multiple projects. This might be
+numerous projects having a similar issue because of design, coding pattern, or
+reuse of the same code (an example of this situation is :cve_nist:`2023-44487`
+where multiple web servers share a design weakness). It might also be a
+high-profile issue in a commonly used library (like OpenSSL). In such cases,
+the project, learning first about the issue, might decide to notify other
+affected projects confidentially so that they come up with a synchronized fix.
+It might also be the affected project informing major distributions to roll out
+the update simultaneously.
+
+Such notifications happen over confidential, non-public means. Typically, the
+project initiating this "embargo" directly notifies a selected number of people
+from each project, including a subset of the security team. When Yocto Project
+is a part of such a notified group, developers prepare fixes on separate
+infrastructure and test it. They might also include additional developers and
+domain experts who can help with the fix and eventual regressions. When the
+embargo is lifted, they send a patch to the relevant public list, and the usual
+review process starts.
+
 Security Team Members
 =====================
 

-- 
2.43.0