On Mon, Aug 03, 2026 at 11:59:58AM +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 | 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. > > - [email protected] > +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 <[email protected]>
signature.asc
Description: PGP signature
