OpenStack vulnerability management

OpenStack security vulnerabilities are carefully handled by the upstream vulnerability management team.

The Fedora OpenStack package maintainers follow a similarly careful process in order to respond to the private notification of issue and make package updates available to users on the public disclosure date:

• A private notification of a vulnerability is received from upstream
• A CVE number is provided some time later
• A tracker bug for this CVE is filed:

product = Security Response
component = vulnerability
alias = CVE-XXXX-XXXX
summary: CVE-XXX-XXXX $package: $title
description: all details from upstream including disclosure date

Note: "Security Sensitive Bug" checkbox is ticked to make sure the information is not yet publicly disclosed.

Use this link to file such a bug.

• Package updates are prepared and tested for the affected branches before the disclosure date - e.g. EPEL6, F16, F17, rawhide. The update is decoupled from any other large updates, allowing it to safely go straight through to the updates repo.
• On the disclosure date, bugs are filed for each of the affected releases:

product = Fedora/Fedora EPEL
component = $package
version = 16/17/el6
keywords = Security, SecurityTracking
blocks = CVE-XXXX-XXXX
summary: CVE-XXX-XXXX $package: $title [$release]
description: please see the bug #XXXXXX for more details on this vulnerability

Note: at this point, the "Security Sensisitive Bug" flag is unchecked in the original tracker bug

Use the following links to file these bugs: epel-6, fedora-17, fedora-16

• The updates are then pushed to fedpkg git, built in koji and filed in bodhi referencing the appropriate bug for that release. Once filed, the packages are tested by others and given karma in order to get it quickly into the updates repo.