diff --git a/security/how-to-report-a-security-vulnerability.md b/security/how-to-report-a-security-vulnerability.md
index 7680936..c242778 100644
--- a/security/how-to-report-a-security-vulnerability.md
+++ b/security/how-to-report-a-security-vulnerability.md
@@ -5,33 +5,49 @@
 public disclosure.
 
 The main ideas are:
- - You have information about a security problem which is not yet
-   publicly available.
+ - You have information about a security problem or vulnerability which is not
+   yet publicly available.
  - You want the problem fixed before public disclosure and
    you are willing to help make that happen.
  - You understand the problem will eventually be publicly disclosed.
 
-To begin the process:
- - Send an email to `openbmc-security at lists.ozlabs.org` with details
-   about the security problem such as:
-   - the version and configuration of OpenBMC the problem appears in
-   - how to reproduce the problem
-   - what are the symptoms
- - As the problem reporter, you will be included in the email thread
-   for the problem.
+To begin the process: Privately contact the OpenBMC security response team and
+(if known) the project maintainer:
+ - Suggest sending an email.  Use `openbmc-security at lists.ozlabs.org`.
+ - If you know which source code repository is affected, find the repository
+   owner or maintainer contact information in the OWNERS or MAINTAINERS file.
+   If not, the security response team will help route the problem.
+ - Include details about the security problem such as:
+   - The version and configuration of OpenBMC the problem appears in.
+   - How to reproduce the problem.
+   - What are the symptoms.
+ - As the problem reporter, you will be included in the problem response.
 
-The OpenBMC security response team (SRT) will respond to you and work to
-address the problem.  Activities may include:
+Please note the OpenBMC project has multiple source code repositories.  Each
+has separate owners.  If you do not know which repository is affected, the
+owner or the security response team can help you route the problem.
+
+When the project owners get a new security problem, they will create a [GitHub
+security advisory][] in their repository and begin work.  The advisory has
+draft status which means only the collaborators can see it.  Collaborators
+should be added as follows:
+ - The problem reporter.
+ - The OpenBMC security response team.
+ - Developers responsible for fixing the problem.
+
+The collaborators work to resolve the problem.  Activities may include:
+ - The OpenBMC [CVE Numbering Authority (CNA)][] (members of the OpenBMC
+   security response team) will help clarify the problem and assign CVEs.
  - Privately engage community members to understand and address the
    problem.  Anyone brought onboard should be given a link to the
    OpenBMC [security response team guidelines][].
  - Work to determine the scope and severity of the problem,
    such as [CVSS metrics][].
- - Work to create or identify an existing [CVE][].
  - Coordinate workarounds and fixes with you and the community.
  - Coordinate announcement details with you, such as timing or
    how you want to be credited.
- - Create an OpenBMC security advisory.
+ - At the agreed time, publish the OpenBMC security advisory, reveal the fix,
+   and publish the CVE.
 
 Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][],
 (SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.
@@ -50,3 +66,5 @@
 [CVSS metrics]: https://www.first.org/cvss/calculator/3.0
 [CVE]: http://cve.mitre.org/about/index.html
 [CERT Guide to Coordinated Vulnerability Disclosure]: https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
+[GitHub security advisory]: https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
+[CVE Numbering Authority (CNA)]: https://www.cve.org/ProgramOrganization/CNAs
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
index 21e3491..34e308d 100644
--- a/security/obmc-security-response-team-guidelines.md
+++ b/security/obmc-security-response-team-guidelines.md
@@ -1,25 +1,26 @@
 # Security response team guidelines
 
-These are the guidelines for the security response team members
-including OpenBMC community members who are responding to problems
-reported by the [security vulnerability reporting process][].
+These are the guidelines for OpenBMC security responders, including the
+security response team, project owners, and community members who are
+responding to problems reported by the [security vulnerability reporting
+process][].
 
-The security response team (SRT) coordinates activity to address privately
-disclosed security vulnerabilities, engages resources to address them,
-and creates security advisories.
+Each project within OpenBMC works independently to resolve security
+vulnerabilities.  The security response team helps the maintainers, provides
+consistency within the OpenBMC project, and helps to get CVEs assigned.
 
 Here are the primary expectations:
- - Keep problems private until announce
- - Work with diligence
- - Keep stakeholders informed
+ - Keep problems private until announce.
+ - Work with diligence.
+ - Keep stakeholders informed.
 
 Workflow highlights:
 
 1. Handle new problem reports.
     - Within a day, acknowledge you received the report.
       Note that reports are archived in the mailing list.
-    - Communicate within the security response team, typically by
-      cc'ing the openbmc-security email list.
+    - Communicate by opening the GitHub draft security advistory as soon as
+      the problem is known.
 
 2. Analyze the problem and engage collaborators as needed (upstream,
    downstream, and OpenBMC).
@@ -30,15 +31,20 @@
        - Note that the problem may be in a customized version of
          OpenBMC but not in OpenBMC itself.
     - Determine which OpenBMC areas should address the problem.
-    - Draft a CVE-like report which includes only:
-       * the vulnerability description: omit OpenBMC specifics
-       * [CVSS metrics][] with explanations as needed
-       * CVE identifiers, if known
-    - Gather data for the security advisory (see template below).
-    - Use private channels, e.g., email.
+    - [Create the draft security advisory][] and populate its fields.
+       - The Ecosystem would normally be "OpenBMC" and the package name
+         is normally the repository.
+       - Please describe when the problem was introduced to help users
+         learn if they are affected.  Use Git tags and commit IDs if
+         known.  It also may be helpful to say what OpenBMC version is
+         affected.  For example, if the problem in the original code
+         through OpenBMC release 2.9, the affected version is "<= 2.9".
+         See [OpenBMC releases][].
+    - Use private channels, for example, email, GitHub draft security
+      advistory, or private direct messaging.
     - Inform contacts this is private work as part of the OpenBMC
       security response team.  For example, link to these guidelines.
-    - Coordinate with all stakeholders and keep them informed.
+    - Coordinate with all collaborators and keep them informed.
 
    Considerations in the [CERT Guide to Coordinated Vulnerability
    Disclosure][] (SPECIAL REPORT CMU/SEI-2017-SR-022) may guide the process.
@@ -62,11 +68,9 @@
         - Consider using [Patch set][] emails to make reviews accessible to
           all stakeholders.
     4. When agreed:
-        - Publish a security advisory to
-          https://github.com/openbmc/openbmc/issues and email list
-          openbmc@lists.ozlabs.org.
+        - Publish a security advisory to the affected openBMC repository.
         - Make the Gerrit review publicly viewable.
-        - Email the Security Advisory to the OpenBMC community (see below).
+        - Publish the CVE in the CVE ddatabase.
     5. Improve OpenBMC processes to avoid future problems.
 
 [security vulnerability reporting process]: ./obmc-security-response-team.md
@@ -74,8 +78,10 @@
 [UEFI Security Response Team (USRT)]: https://uefi.org/security
 [CERT Guide to Coordinated Vulnerability Disclosure]: https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
 [contributing]: https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server
+[OpenBMC releases]: https://github.com/openbmc/docs/blob/master/release/release-notes.md
 [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
 
 ## Template: Initial response to the problem submitter
 The OpenBMC security response team has received the problem.
diff --git a/security/obmc-security-response-team.md b/security/obmc-security-response-team.md
index 7c42698..0093852 100644
--- a/security/obmc-security-response-team.md
+++ b/security/obmc-security-response-team.md
@@ -12,13 +12,17 @@
 
 The basic workflow is:
  1. A community member reports a problem privately to the security
-    response team.
- 2. The response team works to understand the problem and privately
-    engages community members to resolve it.
- 3. Workarounds and fixes are created, reviewed, and approved.
- 4. The security response team creates an OpenBMC security advisory
-    which explains the problem, its severity, and how to protect
-    your systems that were built on OpenBMC.
+    response team (and to the repository maintainers if known).
+ 2. The responders (including the security response team, the
+    repository maintainers, and the problem submitter) work to
+    understand the problem.
+ 3. The repository maintainer creates an OpenBMC security advisory
+    which explains the problem, its severity, and how to protect your
+    systems that were built on OpenBMC.
+ 4. The responders privately engage community members to create
+    workarounds and fixes and to negotiate disclosure dates.
+ 5. The OpenBMC security advisory is published along with any
+    accompanying CVEs.
 
 Note that the OpenBMC security response team is distinct from the
 OpenBMC security working group which remains completely open.
@@ -28,7 +32,7 @@
 vulnerability and get a fix for it before public announcement of the
 vulnerability.
 
-The `openbmc-security@lists.ozlabs.org` email address is the primary
+The `openbmc-security at lists.ozlabs.org` email address is the primary
 communication vehicle between the person who reported the problem and
 the security response team, and the initial communication between the
 security response team members.