This document discusses best practices for vulnerability disclosure processes in open source software projects. It compares the traditional "distro model" process, focused on direct users of the software, to the newer "cloud model" process, which also considers the needs of large service providers hosting many indirect users. The cloud model allows longer pre-disclosure periods so providers can test and deploy fixes before vulnerabilities are publicly announced. The document examines differences in approaches taken by various projects and outlines factors like pre-disclosure list membership, disclosure timelines, and CVE tracking that projects should consider to have robust vulnerability response processes.

1. Lars Kurth
Community Manger, Xen Project
Chairman, Xen Project Advisory Board
Lead CentOS Virtualization SIG
Director, Open Source Business Office, Citrix lars_kurth

3. I
I: Vulnerability Introduced
D: Vulnerability Discovered
Encourage discoverers to report
security issues to security@yourproject
Discoverers are in control
You can’t stop them from releasing or
using information
D

4. A team-effort to ensure that …
• All (known) doors are closed
• All (known) doors are locked
• All (known) windows are
boarded up
• Fences have no (known)
weaknesses
• …

5. XF
R: Vulnerability Reported
T: Triage
A: Vulnerability Announced
F: Fix Available
X: Fix Deployed
Vulnerability is known by the reporter and the security team
Note: It may also be known and used by black hats
Vulnerability is known publicly with no fix available
Vulnerability is known publicly with fix available
Basic
Description
R T A
Patch/fix creation
and validation
Detailed Description,
CVE allocation, …

6. Description, CVE
allocation, …
X
R: Vulnerability Reported
T: Triage
P: Vulnerability Pre-disclosed
A: Vulnerability Announced
F: Fix Available
X: Fix Deployed
Vulnerability is known by the reporter and the security team
Note: It may also be known and used by black hats
Vulnerability is known about by a privileged and small group of users
Vulnerability is known publicly
A
Pre-disclosure period
R P
Patch/fix creation
and validation
FT
Typically fixed time during which the security issue is handled secretly
Ideally 2-3 weeks: Depends on discoverer’s wishes
What can and can’t be done with
privileged information can differ
significantly between projects

7. Linux Kernel/LXC/KVM if reported via OSS Security
Linux Kernel/LXC/KVM if reported via security@kernel.org
OpenStack, QEMU, … for low impact issues
Full
Linux Kernel/LXC/KVM if reported via OSS Security Distros
Linux Distributions (both open source and commercial)
QEMU, Libvirt, oVirt, ...
Responsible
“Distro Model”
OpenStack for intermediate to high impact issues
OPNFV, OpenDayLight : process modeled on OpenStack
Xen Project for all issues (also handles 3rd party issues, e.g. QEMU)
Responsible
“Cloud Model”
Not clearly
stated
Docker : states responsible disclosure; but policy docs empty / some CVEs
Cloud Foundry : no clearly stated process; no published CVE’s
CoreOS: just a mail to report issues
Kubernetes: : just a mail to report issues (when I wrote this talk in Aug, no info)
Approach Used by Projects

8. Linux Kernel/LXC/KVM if reported via OSS Security
Linux Kernel/LXC/KVM if reported via security@kernel.org
OpenStack, QEMU, … for low impact issues
Full
Linux Kernel/LXC/KVM if reported via OSS Security Distros
Linux Distributions (both open source and commercial)
QEMU, Libvirt, oVirt, ...
Responsible
“Distro Model”
OpenStack for intermediate to high impact issues
OPNFV, OpenDayLight : process modeled on OpenStack
Xen Project for all issues (also handles 3rd party issues, e.g. QEMU)
Responsible
“Cloud Model”
Not clearly
stated
Docker : states responsible disclosure; but policy docs empty / some CVEs
Cloud Foundry : no clearly stated process; no published CVE’s
CoreOS: just a mail to report issues
Kubernetes: : just a mail to report issues (when I wrote this talk in Aug, no info)
Approach Used by Projects
OpenNebula

9. What is allowed during pre-disclosure
Who is privileged and trusted to be on the pre-disclosure
mailing list
Pre-Disclosure Time
What can and can’t be done with
privileged information can differ
significantly between projects

10. Make sure that a fix is available before disclosure
Make sure that downstream projects and products (e.g. distros) can
package and test the fix in their environment
Allow service providers that use your Software to start planning an
upgrade (at scale this can take a week)
Allow service providers that use your Software to deploy an upgrade
before the embargo completes

11. Make sure that a fix is available before disclosure
Make sure that downstream projects and products (e.g. distros) can
package and test the fix in their environment
Allow service providers that use your Software to start planning an
upgrade (at scale this can take a week)
Allow service providers that use your Software to deploy an upgrade
before the embargo completes
Cloud Model
Distro Model

12. Emerged recently!
Recognizes the needs of service providers
Pre-Cloud Computing!
Services and their users are vulnerable
immediately after disclosure

14. More Cloud/Service users than direct users of your software
Example:
AWS stated in 2014 that they have > 1M users (and a lot more instances)
AliCloud claims that they have > 1M users
…

15. Just imagine what the reputation damage would have been, if Xen had put AWS,
Rackspace, SoftLayer, … users at real risk of a vulnerability.
There were 100’s of
stories at the time,
despite the fact that
users were never put
at risk, but merely
inconvenienced !

16. Pre-disclosure list membership:
more members, more risk of leakage
In the Distro Model, the number of privileged users is typically <10
In the Cloud Model, the number could be an order of magnitude higher (50-100)

17. Restricting pre-disclosure list membership
Restricting membership to large service providers to minimize risk
Opaque application criteria and process
…
That creates issues of “fairness”
Which may be incompatible with your communities' values

18. Source: yanilavigne.net via
domics.me

19. Very wide range of approaches vs.
The reality that SW stacks contain many layers
Consider the weakest link in your SW stack
Best Practice appears to be emerging, BUT …
Older projects seem slow to change
New projects, don’t build security management into their
culture from the beginning
New Post-Snowden era pressures
How to effectively deal with media Hype?

20. mindfulness @ Flickr

21. Not all projects create CVEs for all their issues
Some projects don’t assign CVEs at all

22. CVE databases (such as www.cvedetails.com) can be used
to evaluate your project
This shows Xen Project CVE stats
Before 2012, we didn’t have fewer vulnerabilities than after
We just didn’t have a process requiring creation of CVEs

23. F AR
Disclosure Time

24. Long disclosure times discredit responsible disclosure
From a few days to many months
Disclosure times need to contribute to your goals & be achievable
Consider the goals of the ”Cloud Model”
Xen Project: 1 week to prepare fix, 2 weeks pre-disclosure
OpenStack: unspecified time to prepare fix, 3-5 working days pre-disclosure

25. Long version of this talk:
www.slideshare.net/xen_com_mgr/
linuxcon-na-2015are-todays-foss-security-practices-robust-enough-in-the-cloud-era
Source: Micky Aldridge
via wikimedia.org