On Mon, Aug 03, 2026 at 11:28:59 +0100, Daniel P. Berrangé via Devel wrote: > From: Daniel P. Berrangé <[email protected]> > > 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é <[email protected]> > --- > 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? [...] > +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/ > +embargoes unless high severity, extenuating circumstances can be > +demonstrated. Reviewed-by: Peter Krempa <[email protected]>
