docs/securityprocess.html.in

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE html>
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4   <body>
   5
   6     <h1>Security Process</h1>
   7
   8     <ul id="toc"></ul>
   9
  10     <p>
  11       The libvirt project believes in responsible disclosure of
  12       security problems, to allow vendors time to prepare and
  13       distribute patches for problems ahead of their publication.
  14       This page describes how the process works and how to report
  15       potential security issues.
  16     </p>
  17
  18     <h2><a id="reporting">Reporting security issues</a></h2>
  19
  20     <p>
  21       In the event that a bug in libvirt is found which is
  22       believed to have (potential) security implications there
  23       is a dedicated contact to which a bug report / notification
  24       should be directed. Send an email with as many details of
  25       the problem as possible (ideally with steps to reproduce)
  26       to the following email address:
  27     </p>
  28
  29     <pre>
  30 <a href="mailto:libvirt-security@redhat.com">libvirt-security@redhat.com</a></pre>
  31
  32     <p>
  33       NB. while this email address is backed by a mailing list, it
  34       is invitation only and moderated for non-members. As such you
  35       will receive an auto-reply indicating the report is held for
  36       moderation. Postings by non-members will be approved by a
  37       moderator and the reporter copied on any replies.
  38     </p>
  39
  40     <h2><a id="secnotice">Security notices</a></h2>
  41
  42     <p>
  43       Information for all historical security issues is maintained in
  44       machine parsable format in the
  45       <a href="https://libvirt.org/git/?p=libvirt-security-notice.git;a=log">libvirt-security-notice GIT repository</a> and
  46       <a href="https://security.libvirt.org">published online</a>
  47       in text, HTML and XML formats. Security notices are published
  48       on the <a href="https://libvirt.org/contact.html#email">libvirt-announce mailing list</a>
  49       when any embargo is lifted, or as soon as triaged if already
  50       public knowledge.
  51     </p>
  52
  53     <h2><a id="seclist">Security team</a></h2>
  54
  55     <p>
  56       The libvirt security team is made up of a subset of the libvirt
  57       core development team which covers the various distro maintainers
  58       of libvirt, along with nominated security engineers representing
  59       the various vendors who distribute libvirt. The team is responsible
  60       for analysing incoming reports from users to identify whether a
  61       security problem exists and its severity. It then works to produce
  62       a fix for all official stable branches of libvirt and co-ordinate
  63       embargo dates between vendors to allow simultaneous release of the
  64       fix by all affected parties.
  65     </p>
  66
  67     <p>
  68       If you are a security representative of a vendor distributing
  69       libvirt and would like to join the security team, send an email
  70       to the afore-mentioned security address. Typically an existing
  71       member of the security team will have to vouch for your credentials
  72       before membership is approved. All members of the security team
  73       are <strong>required to respect the embargo policy</strong>
  74       described below.
  75     </p>
  76
  77     <h2><a id="embargo">Publication embargo policy</a></h2>
  78
  79     <p>
  80       The libvirt security team operates a policy of
  81       <a href="http://en.wikipedia.org/wiki/Responsible_disclosure">responsible disclosure</a>.
  82       As such any security issue reported, that is not already publicly disclosed
  83       elsewhere, will have an embargo date assigned. Members of the security team agree
  84       not to publicly disclose any details of the security issue until the embargo
  85       date expires.
  86     </p>
  87
  88     <p>
  89       The general aim of the team is to have embargo dates which
  90       are two weeks or less in duration. If a problem is identified
  91       with a proposed patch for a security issue, requiring further
  92       investigation and bug fixing, the embargo clock may be restarted.
  93       In exceptional circumstances longer initial embargoes may be
  94       negotiated by mutual agreement between members of the security
  95       team and other relevant parties to the problem. Any such extended
  96       embargoes will aim to be at most one month in duration.
  97     </p>
  98
  99
 100     <h2><a id="cve">CVE allocation</a></h2>
 101
 102     <p>
 103       The libvirt security team will associate each security issue with
 104       a CVE number. The CVE numbers will usually be allocated by one of
 105       the vendor security engineers on the security team.
 106     </p>
 107
 108     <h2><a id="branches">Branch fixing policy</a></h2>
 109
 110     <p>
 111       The libvirt community maintains one or more stable release branches
 112       at any given point in time. The security team will aim to publish
 113       fixes for GIT master (which will become the next major release) and
 114       each currently maintained stable release branch. The distro maintainers
 115       will be responsible for backporting the officially published fixes to
 116       other release branches where applicable.
 117     </p>
 118   </body>
 119 </html>