Update docs about push duty & security fixes (#1578)

* Update docs about push duty & security fixes

* Update to clarify process

docs/server/push-duty.rst

@@ -42,38 +42,18 @@ fine since this helps with testing smaller sets of changes.
 Security Fixes
 ++++++++++++++
 
-Security fixes for addons-server live on a separate private repository:
-
-    * `addons-server-security <https://github.com/mozilla/addons-server-security>`_
-
-To make merging easier, when making a pull request against this repository, the
-remote branch should not be published to one's fork but to the repository
-itself. Once the PR has been reviewed, it should *not* be merged right away.
-Instead, merging to main is part of push duty and happens right before
-tagging::
-
-  $ git checkout main
-  $ git pull
-  $ git fetch security
-  $ git merge security/<branch-name>
-  $ git diff upstream/main
-  $ git push upstream main
-  $ git push security main
-
-.. note:: ``mozilla/addons-server-security`` ``main`` branch should never be
-  pushed to directly without pushing to ``mozilla/addons-server`` ``main``
-  first - the two should always stay in sync.
-
-  This means the merge or edit buttons in github web UI must never be used in
-  that repository.
-
-.. note:: Here we are using ``upstream`` and ``security`` remotes, which point
-  to ``mozilla/addons-server`` and ``mozilla/addons-server-security``,
-  respectively. If your configuration is different you can substitute
-  ``upstream`` and ``security`` for whatever you call the
-  ``mozilla/addons-server`` and ``mozilla/addons-server-security``
-  repositories' remotes.
-
+Security issues against AMO are currently reported in bugzilla. When someone is
+assigned to work on one, they should open a new draft security advisory
+describing the security issue and linking to the bugzilla bug, but not publish
+it. That unlocks the ability to have a private PR and fork to work on the
+issue.
+
+The corresponding private PR should is reviewed as normal but once it has been
+reviewed, it should *not* be merged right away. Instead, it should be called
+out in the release notes for the next release. Merging to ``master`` is part
+of push duty and happens right before tagging, using GitHub regular merge
+functionality on the PR. The advisory can then be closed (it's never
+published).
 
 Tag the repos
 +++++++++++++