Re: [RFC] Propose update of security bug handling process

["Laszlo Ersek" <lersek@redhat.com>]

(Dropping bugs@edk2.groups.io <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