From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Fri, 12 Apr 2019 05:52:05 -0700 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 64DE3C057F47; Fri, 12 Apr 2019 12:52:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-65.rdu2.redhat.com [10.10.120.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id F2377608BB; Fri, 12 Apr 2019 12:52:02 +0000 (UTC) Subject: Re: [RFC] Propose update of security bug handling process To: "Wang, Jian J" Cc: "devel@edk2.groups.io" , "Zimmer, Vincent" , "Cetola, Stephano" , "Gao, Liming" References: From: "Laszlo Ersek" Message-ID: Date: Fri, 12 Apr 2019 14:51:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 12 Apr 2019 12:52:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit (Dropping bugs@edk2.groups.io from the address list, as that should be a list to receive automated Bugzilla email.) On 04/12/19 10:43, Wang, Jian J wrote: > Hi, > > Currently, we generally follow below process to handle security bugs. > But there're no document to describe the detailed working flow. There're > also discussions on lacking of important information, poor issue description > and no timely notification on update, etc. > > "0 - New Security Bug" > -> "1 - Triage" > -> "2 - Mitigation" > -> "3 - Embargo" > -> "4 - Disclosure" > -> "5 - Exit"; > > I have a proposal at following page to elaborate the process and try to address > all problems reported so far. Following content is for discussion only. Once the > process is finalized, it will be moved to official edk2 wiki page. > > https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-issue-process > > Any opinions and suggestions are welcomed. Thanks for working on this! I've skimmed the diagrams. I have one suggestion and one request for clarification. - Suggestion: a CVE number should be requested (if appropriate) as soon as the CVSS score (i.e. the nature of the vulnerability) has been calculated, and it has been determined whether platforms in practice (both physical and virtual) are affected. This is important because vendors should have a common (cross-vendor) reference for tracking the issue even in their own internal systems, and this reference should be available to all vendors internally as soon as upstream determines the issue has security impact. Additionally, as soon as members begin collaborating on actual patches, the patches should carry the CVE number in the subject line(s). - Request for clarification: the Embargo diagram should clarify that vendors are *forbidden* from shipping fixes in their own products, regardless of format, until the embargo is lifted. The point of an embargo is to release/ship the fixes all at once, across all vendors. It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3 Open BZ To Public" / "4.4 Open source the patch". That's the interval when vendors would release their fixes all together. It's *not* OK, for any vendor, to ship their own fixes before "3.5 Announce Embargo End". Yes, this means that some vendors will have to wait on other vendors, and some vendors will have to work more hastily than they are used to, for the sake of other vendors. This is what coordinated/responsible disclosure means, and it aims to benefit the cumulative user base. Thanks Laszlo