openstack
/
ossa
Code Issues Proposed changes

Note the 90-day embargo limit 

Now that Ia501817277a3fed215edd78a8035ad07a90810f0 has merged and
adds a 90-day maximum embargo period, update our instructions,
process documentation and templates accordingly. Also fix a few
locations where we failed to mention StoryBoard (now that we have
covered projects making use of it).

Change-Id: I5fd671910a44d03d25034cf1ea31fb34f695747f
This commit is contained in:
Jeremy Stanley 2020-02-13 20:04:45 +00:00
parent 0eac8eb961
commit 92a5157e2d
2 changed files with 67 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
doc/source/index.rst
View File

@ -35,12 +35,12 @@ and disclose the issue responsibly. We provide two ways to report issues to the
OpenStack Vulnerability Management Team depending on how sensitive the issue
is:
* Search for the corresponding project at https://launchpad.net/ and after
selecting it, click the 'Report a bug' link at the right. Fill in the
'Summary' and 'Further information' fields describing the issue, then
click the 'This bug is a security vulnerability' checkbox near the bottom
of the page before submitting it. This will make the bug Private and only
accessible to the Vulnerability Management Team.
* Search for the corresponding project at https://storyboard.openstack.org/ or
https://launchpad.net/ and after selecting it, click the 'Report a bug' link
at the right. Fill in the 'Summary' and 'Further information' fields
describing the issue, then click the 'This bug is a security vulnerability'
checkbox near the bottom of the page before submitting it. This will make the
bug Private and only accessible to the Vulnerability Management Team.
* If the issue is extremely sensitive or you're otherwise unable to use the
bug tracker directly, please send an E-mail message to one or more of the
@ -57,6 +57,13 @@ is:
* Matthew Thode <mthode@mthode.org>:
`key 0x14b91caaf68c4849f90ca41333ed3fd25afc78ba`_ (details__)
.. note::
All private reports of suspected vulnerabilities are embargoed for a maximum
of 90 days. Unless unusual circumstances arise, any defect reported in
private will be made public within 90 calendar days from when it is received,
even if a solution has not been identified.
.. Static key files are generated with the following command:
( gpg2 --fingerprint 0x97ae496fc02dec9fc353b2e748f9961143495829
gpg2 --armor --export-options export-clean,export-minimal \
@ -151,7 +158,7 @@ How to propose and review a security patch
The patch development and review process for security patches is different
from normal patches in OpenStack. Because the gerrit review process is
public, all security bugs must have patches proposed to and reviewed in
the Launchpad bug report comments.
the StoryBoard or Launchpad report comments.
After a patch for the reported bug has been developed locally, you the patch author need to share that with the community. This is a simple process, but it is different than the normal OpenStack workflow.
@ -160,7 +167,7 @@ After a patch for the reported bug has been developed locally, you the patch aut
git format-patch --stdout HEAD~1 >path/to/local/file.patch
Now you have the patch saved locally and you can attach it in a comment
on the Launchpad bug page.
on the bug page.
* For reviewers, to review that attached patch, run the following command::

87
doc/source/vmt-process.rst
View File

@ -48,12 +48,13 @@ Reception
^^^^^^^^^
A report can be received either as a private encrypted email to one
of the VMT members, or as a Launchpad security bug (check the box
marked "this is a security issue").
of the VMT members, or as a StoryBoard or Launchpad security bug
(check the box marked "this is a security issue").
The first steps performed by the VMT are to confirm the validity of
the report, create a Launchpad bug if necessary, prefix the
description with an `embargo reminder`_, add an ossa bugtask and
the report, create a bug in StoryBoard or Launchpad if one does not
yet exist, prefix the description with an `embargo reminder`_
including an end date for its embargo, add an ossa bugtask and
subscribe the project's core security review team for confirmation
of impact and determination of affected branches. Reports starting
with an *Incomplete* ossa bugtask should have a corresponding
@ -182,9 +183,9 @@ and *submit request* again until you get a confirmation page.
Get assigned CVE
^^^^^^^^^^^^^^^^
MITRE returns the assigned CVE. It is added to the Launchpad bug
(see "link to CVE" at the top-right), and the bug is retitled to
"$TITLE ($CVE)".
MITRE returns the assigned CVE. It is added to the bug (see "link to
CVE" at the top-right in Launchpad or use a story comment in
StoryBoard), and the bug is retitled to "$TITLE ($CVE)".
Embargoed disclosure
^^^^^^^^^^^^^^^^^^^^
@ -196,11 +197,11 @@ excluding Monday/Friday and holiday periods, at 1500 UTC. No
stakeholder is supposed to deploy public patches before disclosure
date.
Once the email is sent, the ossa bugtask status should be set to
*Fix committed*. At that point we can also add downstream
stakeholders to the Launchpad bug, if they use Launchpad for
security patches. This means adding ~canonical-security to the bug
subscribers.
Once the email is sent, the OSSA bugtask status should be set to
*Fix committed* if the report uses Launchpad. At that point we can
also add downstream stakeholders to the bug. This means adding
~canonical-security to the bug subscribers in Launchpad, for
example.
For non-embargoed, public vulnerabilities no separate downstream
advance notification is sent. Instead the OSSA bugtask is set to fix
@ -218,7 +219,7 @@ On the disclosure hour, open bug, push patches to Gerrit for review
on master and supported stable branches, fast-track approvals
(referencing the bug).
Update the Launchpad bug title to "[OSSA-$NUM] $TITLE".
Update the bug title to "[OSSA-$NUM] $TITLE".
Embargo reminder can be removed at that point.
@ -247,6 +248,14 @@ number is correctly identified in commit messages then it will be
automatically updated to reflect this as well). Subsequent security
point releases of affected software may then be tagged if warranted.
Abnormal embargo termination
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If a report is held in embargo for 90 days without a fix, or
significant details of the report are disclosed in a public venue,
the embargo is terminated by a VMT coordinator at that time and
subsequent process switches to the public report workflow instead.
Incident Report Taxonomy
------------------------
@ -348,11 +357,8 @@ Embargo exceptions
To keep the embargo period short and effective, the VMT may
choose to open bug reports. Issues that take too much time
to be fixed (e.g., more than 2 weeks) or issues that require
a complex patch are usually better solved in the open.
Whenever such a case occurs, the ossg-coresec group is
subscribed to the bug report in order to discuss whether or not
it's imperative to keep that particular bug private.
a complex patch are usually better solved in the open. Only under
unusual circumstances should any embargo extend past 90 days.
Downstream stakeholders
^^^^^^^^^^^^^^^^^^^^^^^
@ -378,27 +384,38 @@ Templates
Reception incomplete message (unconfirmed issues)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.
::
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.
Reception embargo reminder (private issues)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments.
::
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past $NINETY_DAYS and will be made
public by or on that date if no fix is identified.
The NINETY_DAYS value should be 90 days from the date the report is
accepted by the coordinator and project reviewers are subscribed. It
can be trivially calculated with the ``date -I -d90days`` shell
command.
Impact description ($DESCRIPTION)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^