Possible improvement to Xen Security Response Process

[Matthew Allen <matthew.allen@citrix.com>]

According to https://xenbits.xen.org/xsa/ we are in the middle of 
4 consecutive Tuesdays of security announcements: XSA-19[1-8]
on Nov. 22, XSA-201 Nov. 29, XSA-199 Dec. 6 and XSA-200 Dec. 13.
The present security policy does not encourage batching of XSAs and
I would like us to consider refining the policy to permit this.

The present approach of frequent security updates causes significant 
disruption to users.  Many organisations test updates before deploying
in production; because security updates are so important this displaces 
other work at short notice and doing so repeatedly is a significant
impact to users of Xen.  Updating the policy to encourage the batching
of updates would reduce the load of using Xen.

From a security purist point of view, any delay in publication could 
increase the possibility of vulnerabilities being exploited in the
wild.  However, given the significant frequency of publication of XSAs,
I’d suggest that users failing to keep up with the publication rate
is presently a much greater security risk.

If XSAs were to be batched, we should also consider if batch updates 
should be encouraged to be on pre-defined dates.  The present
unpredictability makes it unnecessarily more difficult for users of
Xen to plan their lives.  For example, our present process causes 
organisations with few administrators to choose between cancelling
holidays or not patching.

Obviously, some issues are discussed in public before the security 
impact is realised (such as XSA-201); equally, the right to set 
a disclosure date (if any) rests with the discoverer.  However,
my experience of other software (which may not be typical) has been
that discoverers are usually happy to go along with any reasonable
proposed date given in the same way that discoverers of XSAs are
usually happy to conform to our present policy.

If this seems a good idea, then I’ll post a concrete proposal but 
I’d like to get general feedback first.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel