Update SECURITY.md with anza links and names

SECURITY.md

@@ -5,11 +5,11 @@
 2. [Incident Response Process](#process)
 
 <a name="reporting"></a>
-## Reporting security problems in the Solana Labs Validator Client
+## Reporting security problems in the Agave Validator
 
 **DO NOT CREATE A GITHUB ISSUE** to report a security problem.
 
-Instead please use this [Report a Vulnerability](https://github.com/solana-labs/solana/security/advisories/new) link.
+Instead please use this [Report a Vulnerability](https://github.com/anza-xyz/agave/security/advisories/new) link.
 Provide a helpful title, detailed description of the vulnerability and an exploit
 proof-of-concept. Speculative submissions without proof-of-concept will be closed
 with no further consideration.
@@ -25,13 +25,13 @@ Expect a response as fast as possible in the advisory, typically within 72 hours
 --
 
 If you do not receive a response in the advisory, send an email to
-security@solanalabs.com with the full URL of the advisory you have created.  DO NOT
+security@anza.xyz with the full URL of the advisory you have created.  DO NOT
 include attachments or provide detail sufficient for exploitation regarding the
 security issue in this email. **Only provide such details in the advisory**.
 
-If you do not receive a response from security@solanalabs.com please followup with
+If you do not receive a response from security@anza.xyz please followup with
 the team directly. You can do this in the `#core-technology` channel of the
-[Solana Tech discord server](https://solana.com/discord), by pinging the `Solana Labs`
+[Solana Tech discord server](https://solana.com/discord), by pinging the `Anza`
 role in the channel and referencing the fact that you submitted a security problem.
 
 <a name="process"></a>
@@ -42,18 +42,18 @@ followed to contain, respond and remediate:
 
 ### 1. Accept the new report
 In response a newly reported security problem, a member of the
-`solana-labs/admins` group will accept the report to turn it into a draft
-advisory.  The `solana-labs/security-incident-response` group should be added to
+`anza-xyz/admins` group will accept the report to turn it into a draft
+advisory.  The `anza-xyz/security-incident-response` group should be added to
 the draft security advisory, and create a private fork of the repository (grey
 button towards the bottom of the page) if necessary.
 
 If the advisory is the result of an audit finding, follow the same process as above but add the auditor's github user(s) and begin the title with "[Audit]".
 
-If the report is out of scope, a member of the `solana-labs/admins` group will
+If the report is out of scope, a member of the `anza-xyz/admins` group will
 comment as such and then close the report.
 
 ### 2. Triage
-Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the solana-labs/security-incident-response group may add other github users to the advisory to assist.
+Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the anza-xyz/security-incident-response group may add other github users to the advisory to assist.
 If it is determined that this is not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created.
 
 ### 3. Prepare Fixes
@@ -62,18 +62,11 @@ There is no CI available in the private repository so you must build from source
 Code review from the reporter is ideal, as well as from multiple members of the core development team.
 
 ### 4. Notify Security Group Validators
-Once an ETA is available for the fix, a member of the solana-labs/security-incident-response group should notify the validators so they can prepare for an update using the "Solana Red Alert" notification system.
+Once an ETA is available for the fix, a member of the anza-xyz/security-incident-response group should notify the validators so they can prepare for an update using the "Solana Red Alert" notification system.
 The teams are all over the world and it's critical to provide actionable information at the right time. Don't be the person that wakes everybody up at 2am when a fix won't be available for hours.
 
 ### 5. Ship the patch
-Once the fix is accepted, a member of the solana-labs/security-incident-response group should prepare a single patch file for each affected branch. The commit title for the patch should only contain the advisory id, and not disclose any further details about the incident.
-Copy the patches to https://release.solana.com/ under a subdirectory named after the advisory id (example: https://release.solana.com/GHSA-hx59-f5g4-jghh/v1.4.patch). Contact a member of the solana-labs/admins group if you require access to release.solana.com
-Using the "Solana Red Alert" channel:
-    a) Notify validators that there's an issue and a patch will be provided in X minutes
-    b) If X minutes expires and there's no patch, notify of the delay and provide a new ETA
-    c) Provide links to patches of https://release.solana.com/ for each affected branch
-Validators can be expected to build the patch from source against the latest release for the affected branch.
-Since the software version will not change after the patch is applied, request that each validator notify in the existing channel once they've updated. Manually monitor the roll out until a sufficient amount of stake has updated - typically at least 33.3% or 66.6% depending on the issue.
+Once the fix is accepted it may be distributed directly to validators as a patch, depending on the vulnerability.
 
 ### 6. Public Disclosure and Release
 Once the fix has been deployed to the security group validators, the patches from the security advisory may be merged into the main source repository. A new official release for each affected branch should be shipped and all validators requested to upgrade as quickly as possible.