@@ -108,6 +108,18 @@ The assessment phase is primarily a technical evaluation period where PSIRT Engi
- Variant Hunting: Search for related vulnerabilities or attack vectors
- Mitigation Identification: Identify potential mitigations and workarounds
### Handling Breaking Changes
When evaluating a solution that risks a breaking change, the PSIRT engineer should verify and assist:
- Is this solution secure by default?
- Per the [breaking change template](https://gitlab.com/gitlab-com/Product/-/blob/main/.gitlab/issue_templates/Breaking-Change-Exception.md?ref_type=heads), PSIRT could assist in the following areas:
- In the _Executive Summary_ section: PSIRT is the natural owner of confirming whether a breaking change qualifies under the "_significant security risk - Severity 1 or 2_" criterion. The team should validate the severity rating and confirm the security justification.
- In the _"Can we get the same outcome without a breaking change?"_ section: PSIRT can provide input on whether alternative fixes exist that avoid breaking changes, or confirm that the breaking approach is the only viable remediation.
- In the _"When do you want to make the breaking change?"_ section: PSIRT should weigh in on timing, especially when vulnerability SLAs or FedRAMP remediation deadlines constrain the timeline.
- In the _Customer Communication_ section: PSIRT should review customer-facing copy to ensure it doesn't over-disclose vulnerability details while still explaining why the breaking change is necessary. There's also the question of coordinating with the security release blog post vs. the general breaking change comms.
- In the _Deprecation issue linkage_ section: The template says to create a public deprecation issue after VP approval. For security-motivated changes, PSIRT should review what goes into that public issue to avoid premature disclosure.
## PSIRT Validation Workflow
The verification phase serves as a quality gate to ensure vulnerabilities are properly resolved before moving to the release process. The remediation and verification phases work in a loop \- if the fix is determined to be insufficient during validation, the process returns to engineering remediation for additional work until the fix is deemed complete and sufficient.
