mirror of
https://github.com/libvirt/libvirt.git
synced 2026-10-02 12:20:06 -05:00
Daniel P. Berrangé
d3f61e00b4
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. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
89 lines
3.7 KiB
ReStructuredText
89 lines
3.7 KiB
ReStructuredText
================
|
|
Security Process
|
|
================
|
|
|
|
.. contents::
|
|
|
|
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
|
|
-------------------------
|
|
|
|
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
|
|
`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.
|
|
|
|
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 assigned
|
|
to a security issue before a patch is ready to be posted (see below).
|
|
|
|
Note: Refer to the `bug reporting <bugs.html#use-of-automated-tools-ai-agents>`__
|
|
page for the *expectations around the use of automated tools and AI agents*,
|
|
**prior** to filing any security report.
|
|
|
|
Security notices
|
|
----------------
|
|
|
|
Information for all historical security issues is maintained in machine parsable
|
|
format in the `libvirt-security-notice GIT
|
|
repository <https://gitlab.com/libvirt/libvirt-security-notice>`__ and
|
|
`published online <https://security.libvirt.org>`__ in text, HTML and XML
|
|
formats. Security notices are published on the `libvirt-announce mailing
|
|
list <contact.html#mailing-lists>`__ when any embargo is
|
|
lifted, or as soon as triaged if already public knowledge.
|
|
|
|
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 libvirt maintainers consider that any disclosure originating
|
|
from automated tools is highly likely to be independently re-discovered,
|
|
potentially many times over in a very short timeframe.
|
|
|
|
Thus the libvirt maintainers will generally reject requests for arbitrary
|
|
embargoes unless high severity, extenuating circumstances can be
|
|
demonstrated.
|
|
|
|
If a patch for a confirmed security issue cannot be developed by a
|
|
maintainer in a reasonable time, the maintainers may choose to make
|
|
a disclosure public without having a patch available. This approach
|
|
should only be taken for issues judged to have low severity.
|
|
|
|
CVE allocation
|
|
--------------
|
|
|
|
If a reported disclosure is confirmed to be a security flaw, the
|
|
``CVE::Required`` label will be added.
|
|
|
|
When a CVE has been allocated, this label will be removd and replaced
|
|
by ``CVE::Assigned``.
|
|
|
|
The allocated CVE identifier will be included in the patch(es) that
|
|
are required to fix the issue. If multiple patches are involved, the
|
|
CVE must be included in the final patch in the series that closes the
|
|
last hole, but should also be included in any prior patches it the
|
|
series that are directly related.
|
|
|
|
Branch fixing policy
|
|
--------------------
|
|
|
|
The security team will publish fixes for GIT master (which will become the next
|
|
major release). The distro maintainers will be responsible for backporting the
|
|
officially published fixes to other release branches where applicable.
|