I agree w/ your comments Jian. Great input from Lazlo, too. I also want to let the community know that this specific process posting has 2 parts.
This first was to post the process used by infosec bz team today, which Jian did well with https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-issue-process. Goal is to provide transparency into a process that we all agree can use some 'optimization.' The 'optimization' is the second part of the discussion, namely refining the process, and some of the results of the RFC. To that end, our able community manager Stephano will set up meetings for continuing to execute the scrubs in addition to and/or along with actions to refine the process. Thanks, Vincent -----Original Message----- From: Wang, Jian J Sent: Sunday, April 14, 2019 10:36 PM To: devel@edk2.groups.io; ler...@redhat.com Cc: Zimmer, Vincent <vincent.zim...@intel.com>; Cetola, Stephano <stephano.cet...@intel.com>; Gao, Liming <liming....@intel.com> Subject: RE: [edk2-devel] [RFC] Propose update of security bug handling process Laszlo, > -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Laszlo Ersek > Sent: Friday, April 12, 2019 8:52 PM > To: Wang, Jian J <jian.j.w...@intel.com> > Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zim...@intel.com>; > Cetola, Stephano <stephano.cet...@intel.com>; Gao, Liming > <liming....@intel.com> > Subject: Re: [edk2-devel] [RFC] Propose update of security bug > handling process > > (Dropping b...@edk2.groups.io <b...@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-secu > > rity- > 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). > No strong opinion. If no objection, let's do as you suggested. > > - 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. I think it's impractical to ask all vendors to release the fixes at the same time. The longer a security issue exists in a product, the more damage may be caused potentially. I don't think any vendor want to risk that. But it's reasonable and feasible to ask vendors not to expose the issue details in the embargo period. So my understanding is that embargo is for preparing the security issue information disclosure purpose, during which all vendors should integrate the mitigation solution into their products. Actually, once someone else find the same issue and open it to public in the period, we should end the embargo immediately. This step is missing in the work flow chart. Vincent, please correct me if anything wrong here. Regards, Jian > > Thanks > Laszlo > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39136): https://edk2.groups.io/g/devel/message/39136 Mute This Topic: https://groups.io/mt/31055577/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
