On Mon, Aug 03, 2026 at 11:59:58AM +0100, Daniel P. Berrangé via Devel wrote:
From: Daniel P. Berrangé <berrange@redhat.com>
Use of email for security disclosures is not a sustainable approach in the new world with countless LLM assisted security researchers.
The old security approach has been to keep disclosures visible to a very small number of hand-picked maintainers, on the assumption that information has to be highly classified. This view is no longer valid with LLMs assisted research, as multiple people can report the same flaw within a short window of time. It is assumed that anyone with access to LLMs will be capable of re-discovering issues at any time.
As such there is less compelling benefit to limiting the visibility of disclosures originating with LLMs. Rather than try to distinguish which disclosures come purely from humans vs those assisted by LLMs, just assume LLMs will be involved as that is the common case. Thus make disclosures visible to all maintainers immediately.
By the same rational of repeated re-discovery there is also less benefit to applying embargoes to issues once a fix is available. Thus this proposal intends to make CVEs public as soon as a fix is proposed for merge.
With this new open approach to disclosures, there is then no reason to have a separate process for disclosing regular bugs vs security issues. By using the regular bug tracker for security disclosures, the process can be simplified and gain access to better tools for tracking & triage than email offers.
Thus the new security disclosure process is simply with bug tracking process with two add-ons:
* The initial disclosure has the "confidential" flag set * The use of "CVE::Required" and "CVE::Assigned" labels to handle CVE allocation.
This is essentially identical to the process adopted by QEMU last month which has been successful at scaling the triage process.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/securityprocess.rst | 96 +++++++++++++++++++--------------------- 1 file changed, 45 insertions(+), 51 deletions(-)
diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst index b7695ddc59..61261c82b0 100644 --- a/docs/securityprocess.rst +++ b/docs/securityprocess.rst @@ -4,30 +4,30 @@ Security Process
.. contents::
-The libvirt project believes in responsible disclosure of security problems, to -allow vendors time to prepare and distribute patches for problems ahead of their -publication. This page describes how the process works and how to report -potential security issues. +The libvirt project handles security disclosures with a lightweight process +whose aim is to minimize the overhead of triage and prioritize publication +of a patch that addresses the issue.
Reporting security issues -------------------------
-In the event that a bug in libvirt is found which is believed to have -(potential) security implications there is a dedicated contact to which a bug -report / notification should be directed. Send an email with as many details of -the problem as possible (ideally with steps to reproduce) to the following email -address: +Security concerns should be reported as confidential issues in the +`libvirt project on GitLab <https://gitlab.com/libvirt/libvirt/-/work_items>`__, or one of the other related projects under the
Line is too long.
+`libvirt namespace <https://gitlab.com/libvirt/>`__ if the issue does not +apply to the core project.
-:: +Ensure that the "**turn on confidentiality**" checkbox is selected prior to +submitting the issue, to restrict visibility to project maintainers only.
- security@lists.libvirt.org +Maintainer(s) will analyse the reported disclosure and decide whether it +is to be classed as a security flaw or not. If not a security flaw, the +``confidential`` tag will be removed immediately. If a security flaw, +the maintainers will work to develop and test a patch. When a suitable +patch is considered ready to post to the mailing list or a merge request, +the ``confidential`` tag will be removed. Generally a CVE should be assignd
s/assignd/assigned/ Reviewed-by: Pavel Hrdina <phrdina@redhat.com>