On Mon, Aug 03, 2026 at 12:52:22PM +0200, Peter Krempa wrote:
On Mon, Aug 03, 2026 at 11:28:59 +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 | 94 ++++++++++++++++++---------------------- 1 file changed, 43 insertions(+), 51 deletions(-)
diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst index b7695ddc59..0cc1349b9e 100644 --- a/docs/securityprocess.rst +++ b/docs/securityprocess.rst @@ -4,30 +4,28 @@ Security Process
[...]
+Security concerns in libvirt should be reported as confidential issues in +the appropriate `project on GitLab. <https://gitlab.com/libvirt>`__.
Should we perhaps add (e.g. as example) link to libvirt project itself too for lazy clicks?
Yeah, that's probably a good idea. Worst case we can move bugs to other projects if desired, but chances are, almost all of them will be applying to libvirt.git
[...]
+Publication embargo policy +--------------------------
[...]
+The libvirt project policy is to limit the time that a disclosure has the +"*confidential*" marker applied strictly to the minimum required to develop +and publish a suitable patch and allocate a CVE.
[...]
+Given the widespread use of AI/LLM based agents for security auditing, +as well as ongoing use of traditional fuzzing and static analysis +tools, the QEMU maintainers consider that any disclosure originatinga
s/QEMU/libvirt/
+from automated tools is highly likely to be independently re-discovered, +potentially many times over in a very short timeframe.
-Publication embargo policy --------------------------- +Thus the QEMU maintainers will generally reject requests for arbitrary
s/QEMU/libvirt/
</face-palm> guess where I copy & pasted from :-)
+embargoes unless high severity, extenuating circumstances can be +demonstrated.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|