Add maintainer flow to create security advisories

This enhances the security response guidelines with process steps for
repo maintainers to create new security advisories, and provides
guidance for what to put into the advisory.

Signed-off-by: Joseph Reynolds <joseph-reynolds@charter.net>
Change-Id: Icc3f737d0d845d651eaf70853ed55529dacf7a93
diff --git a/security/obmc-github-security-advisory-template.md b/security/obmc-github-security-advisory-template.md
new file mode 100644
index 0000000..04366f4
--- /dev/null
+++ b/security/obmc-github-security-advisory-template.md
@@ -0,0 +1,58 @@
+# OpenBMC Security Advisory Template
+
+This has guidelines for OpenBMC repository maintainers to follow when creating
+new draft GitHub security advisories as part of the [Security response team
+guidelines][].
+
+Note that the sections under the "Description" section are intended for the
+security advisory "Description" field
+
+[Security response team guidelines]: ./obmc-security-response-team-guidelines.md
+
+### Affected Product
+Ecosystem: Other        OpenBMC
+Package name:           <TBD>
+Affected versions:      2.9
+Patched versions:       <TBD>
+
+## Severity
+Assess the severity using CVSS.
+
+## CWE
+<TBD>
+
+## CVE identifier
+Please coordinate with the security response team
+
+## Credits
+Attribution to those that discovered and mitigated the vulnerability.
+
+### Title
+Title goes here...
+
+### Description
+The description will be used by vulnerability analysts and should include the
+area or the function affected, and a description of the issue.  There should
+be enough details to differentiate this from similar problems, but not enough
+detail to help an attacker exploit the problem.
+
+### Proof Of Concept
+If provided, insert proof of concept here.
+
+### Vulnerability Description
+...can cause denial of service.
+
+### Affected Release
+OpenBMC 2.9
+
+### Fixed in Release
+Please include the commit-id in the affected repo, the commit id for the
+metadata, or the version number.
+
+### Mitigation
+If available, describe or provide a link to the mitigation needed until the
+fix can be applied.
+
+### For more information
+If you have any questions or comments about this advisory:
+* Email openbmc-security at lists.ozlabs.org
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
index 34e308d..08844e0 100644
--- a/security/obmc-security-response-team-guidelines.md
+++ b/security/obmc-security-response-team-guidelines.md
@@ -68,11 +68,32 @@
         - Consider using [Patch set][] emails to make reviews accessible to
           all stakeholders.
     4. When agreed:
-        - Publish a security advisory to the affected openBMC repository.
+        - Publish a security advisory to the affected OpenBMC repository.
         - Make the Gerrit review publicly viewable.
-        - Publish the CVE in the CVE ddatabase.
+        - Publish the CVE in the CVE database.
     5. Improve OpenBMC processes to avoid future problems.
 
+Repository maintainer process steps:
+    1. Create a private gerrit code review and oversee development of the fix.
+    2. Create a draft advisory under github.com/openbmc/<REPO>/security/advisories.
+       Please follow guidance in the [OpenBMC Security Advisory Template][].
+       Add the openbmc security-response group and other stakeholders to the advisory.
+    3. Review the security bulletin with stakeholders to get it ready to publish.
+    4. Work with the SRT to identify CVEs.
+       If you are unsure what counts as a vulnerability, please consult with the SRT.
+       For example, independent bugs should have separate CVEs.  A security advisory
+       can reference multiple CVEs.
+       When the CVE is known, add it to the security advisory, and reference
+       it in the commit message, stating how the fix relates to the CVE.  For
+       example: This fixes CVE-yyyy-nnnnn.  Doing so helps downstream security
+       responders.  If the commit is a partial fix, please explain that and
+       provide references to the other parts of the fix.
+    5. If stakeholders negotiate for coordinated disclosure, plan to release
+       the fix and the security advisory on the negotiated day.
+    6. When the code fix and the advisory are both ready (subject to coordinated
+       disclosure), please merge the fixes (and make any private review be public)
+       publish the security advisory, and email the security-response team.
+
 [security vulnerability reporting process]: ./obmc-security-response-team.md
 [CVSS metrics]: https://www.first.org/cvss/calculator/3.0
 [UEFI Security Response Team (USRT)]: https://uefi.org/security
@@ -82,6 +103,7 @@
 [private change]: https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
 [Patch set]: https://en.wikipedia.org/wiki/Patch_(Unix)
 [Create the draft security advisory]: https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
+[OpenBMC Security Advisory Template]: obmc-github-security-advisory-template.md
 
 ## Template: Initial response to the problem submitter
 The OpenBMC security response team has received the problem.