Latest revision as of 15:49, 14 April 2015

Vulnerability Management documentation has moved

to http://security.openstack.org/vmt-process.html but the entries below are retained for the benefit of older deep links, bookmarks and search engine indexing.

Supported versions

Process

Reception

Patch development

Patch review

Draft impact description

Review impact description

CVE assignment

Get assigned CVE

Embargoed disclosure

Open bug, push patches

Publish OSSA

Incident report taxonomy

Extent of disclosure

Downstream stakeholders

Templates

Reception Incomplete Message (unconfirmed issues)

Reception Embargo Reminder (private issues)

Impact description ($DESCRIPTION)

CVE request email (private issues)

CVE request email (public issues)

Downstream stakeholders notification email (private issues)

OpenStack Security Advisories

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Vulnerability Management =
+= [http://security.openstack.org/vmt-process.html Vulnerability Management] documentation has moved =
-== Team ==
+to http://security.openstack.org/vmt-process.html but the entries below are retained for the benefit of older deep links, bookmarks and search engine indexing.
-The [https://launchpad.net/~openstack-vuln-mgmt OpenStack vulnerability management team] is responsible for coordinating the progressive disclosure of a vulnerability.
-Members of the team are independent and security-minded folks that will '''not''' give prior notice to their employer before other downstream users. Membership to the team is not about getting advance notice: it's about making sure vulnerabilities are handled in a quick, secure and fair way. In order to reduce the disclosure of vulnerability in the early stages, this team is voluntarily kept very small (maximum of 3 people).
+==== [http://security.openstack.org/vmt-process.html#supported-versions Supported versions] ====
+==== [http://security.openstack.org/vmt-process.html#process Process] ====
-== Classification ==
+==== [http://security.openstack.org/vmt-process.html#reception Reception] ====
-Each incoming vulnerability will be classified into one of three categories, each triggering a different workflow.
+==== [http://security.openstack.org/vmt-process.html#patch-development Patch development] ====
+==== [http://security.openstack.org/vmt-process.html#patch-review Patch review] ====
-{| border="1" cellpadding="2" cellspacing="0"
+==== [http://security.openstack.org/vmt-process.html#draft-impact-description Draft impact description] ====
-|<#eeeeee>| Level
+==== [http://security.openstack.org/vmt-process.html#review-impact-description Review impact description] ====
-|<#eeeeee>| Description
+==== [http://security.openstack.org/vmt-process.html#cve-assignment CVE assignment] ====
-|-
+==== [http://security.openstack.org/vmt-process.html#get-assigned-cve Get assigned CVE] ====
-|  Critical
+==== [http://security.openstack.org/vmt-process.html#embargoed-disclosure Embargoed disclosure] ====
-|  Directly-exploitable vulnerability, allowing the attacker to escalate rights, take down VMs...
+==== [http://security.openstack.org/vmt-process.html#open-bug-push-patches Open bug, push patches] ====
-|-
+==== [http://security.openstack.org/vmt-process.html#publish-ossa Publish OSSA] ====
-|  Normal
+==== [http://security.openstack.org/vmt-process.html#incident-report-taxonomy Incident report taxonomy] ====
-|  Indirect vulnerability that could result in security issue under certain circumstances.
+==== [http://security.openstack.org/vmt-process.html#extent-of-disclosure Extent of disclosure] ====
-|-
+==== [http://security.openstack.org/vmt-process.html#downstream-stakeholders Downstream stakeholders] ====
-|  Low
+==== [http://security.openstack.org/vmt-process.html#templates Templates] ====
-|  Non-exploitable vulnerabilities due to architectural choices that could be improved
+==== [http://security.openstack.org/vmt-process.html#reception-incomplete-message-unconfirmed-issues Reception Incomplete Message (unconfirmed issues)] ====
-|}
+==== [http://security.openstack.org/vmt-process.html#reception-embargo-reminder-private-issues Reception Embargo Reminder (private issues)] ====
+==== [http://security.openstack.org/vmt-process.html#impact-description-description Impact description ($DESCRIPTION)] ====
-== Process ==
+==== [http://security.openstack.org/vmt-process.html#cve-request-email-private-issues CVE request email (private issues)] ====
+==== [http://security.openstack.org/vmt-process.html#cve-request-email-public-issues CVE request email (public issues)] ====
-Each security bug is assigned a VMT ''coordinator'' (member from the vulnerability management team) that will drive the fixing and disclosure process. Here are the steps to follow (depending on whether the entry comes from an encrypted mail or a Launchpad report), together with the width of disclosure at each step.
+==== [http://security.openstack.org/vmt-process.html#downstream-stakeholders-notification-email-private-issues Downstream stakeholders notification email (private issues)] ====
+==== [http://security.openstack.org/vmt-process.html#openstack-security-advisories OpenStack Security Advisories] ====
-=== From Encrypted email ===
-{| border="1" cellpadding="2" cellspacing="0"
-|<#eeeeee>| Phase
-|-
-|  Receive encrypted email from original reporter
-|-
-|  Warn PTL of affected project, confirmation of impact
-|-
-|  Create security-restricted Launchpad bug entry
-|}
-=== From Launchpad bug entry ===
-{| border="1" cellpadding="2" cellspacing="0"
-|<#eeeeee>| Phase
-|-
-|  Receive bug report, assign coordinator
-|-
-|  Warn PTL of affected project, confirmation of impact
-|}
-=== Coordinated disclosure ===
-{| border="1" cellpadding="2" cellspacing="0"
-|<#eeeeee>| Phase
-|-
-|  Develop fix with original reporter, PTL (and a few other core developers if needed)
-|-
-|  Get fix pre-approved by Core team
-|-
-|  Communicate issue and fix to downstream users, define public disclosure date/time
-|-
-|  At disclosure date: Get core developers ready, push fix to Gerrit and have them approve it
-|-
-|  Distributions deploy fixes
-|-
-|  Issue advisories, open bug

Difference between revisions of "Vulnerability Management"

Latest revision as of 15:49, 14 April 2015

Vulnerability Management documentation has moved