DOC Add security release review process

README.md

@@ -8,6 +8,8 @@ identify risks in generative AI systems.
 
 - Check out our [website](https://microsoft.github.io/PyRIT/) for more information
   about how to use, install, or contribute to PyRIT.
+- Review our [security policy](https://github.com/microsoft/PyRIT/security/policy)
+  to report vulnerabilities privately through the Microsoft Security Response Center.
 - Visit our [Discord server](https://discord.gg/9fMpq3tc8u) to chat with the team and community.
 
 ## Trademarks and Citations

doc/contributing/10_release_process.md

@@ -11,6 +11,23 @@ Follow the instructions according to the order provided.
 
 Before starting the release process, verify the codebase is in a healthy state.
 
+### Required Release Reviews
+
+Use the existing release work item to record:
+
+- Release owner and target version
+- Links to the UI, documentation, and release notes
+- One reviewer each for development, security, content publishing, and user experience
+
+| Checkpoint | Timing | Completion criteria |
+|---|---|---|
+| Scope freeze | Before release testing | Reviewers assess planned customer-facing changes. Security and compatibility findings are linked and assigned. |
+| Final release candidate | Immediately before publishing | Reviewers approve the final UI, documentation, and release notes. High-priority findings are resolved or covered by an approved customer disclosure. |
+
+Do not publish until all final approvals, including reviewer names and dates, are
+recorded in the release work item. Store details about security vulnerabilities that
+have not yet been publicly disclosed only in the approved private security system.
+
 - **Check for pending changes.** Ask other PyRIT maintainers whether they have any in-flight changes that should land before the release.
 - **Verify build pipelines.** Confirm that all integration tests and end-to-end tests are passing in the CI pipelines. If any tests are failing, fix them before proceeding.
   - **Partner integration tests.** Ensure the partner integration tests are also passing. These tests validate that we are not breaking contracts with partner teams (e.g., Foundry). If any are failing, coordinate with the affected partner teams before proceeding with the release.
@@ -254,6 +271,16 @@ since `downgrade()` risks data loss.
 
 ## 10. Publish to PyPI
 
+Before publishing, complete and retain this checklist in the release work item:
+
+- [ ] Technical reviews of the final customer-facing content and UI are complete, and all high-priority feedback is resolved or has an approved disposition.
+- [ ] Scope-freeze and final-release-candidate reviews are recorded.
+- [ ] The final development, content publishing, security, and user experience approvals are recorded with reviewer names and dates.
+- [ ] Release notes contain the required security and compatibility disclosures described in step 12, including explicit "None known" statements where applicable.
+- [ ] Links to review evidence and the final approved artifacts are retained in the release work item.
+
+Do not publish the package until every item is complete.
+
 Create an account on pypi.org if you don't have one yet.
 Ask one of the other maintainers to add you to the `pyrit` project on PyPI.
 
@@ -290,11 +317,30 @@ Make sure that it starts where the last release left off.
 Sometimes this tool adds too many changes, or leaves a few out, so it's best to check.
 Be sure to check and update the new contributors as well.
 Add a header "## Full list of changes" below "## What's changed?".
-In addition to the full notes, we also want a shorter section with just the relevant
-changes that users should be aware of. The shorter section will be under "## What's changed"
-while the full list of changes will be right below.
-Maintenance changes, build pipeline updates, and documentation fixes are not really important for users.
-However, important bug fixes, new features, and breaking changes are good candidates to include.
+Under "## What's changed", summarize the important bug fixes and features that
+customers should know about. Maintenance changes, build pipeline updates, and routine
+documentation fixes can remain in the full list only.
+
+Every release must include these customer-facing sections before "## Full list of changes":
+
+```markdown
+## Security
+
+Describe security fixes and any known high-priority security issues that customers
+must consider, including affected versions and recommended actions. If there are no
+known issues to disclose, write "No known high-priority security issues."
+
+## Breaking changes and compatibility
+
+Describe breaking changes, backward-compatibility issues, affected versions, and
+migration or mitigation steps. If there are none, write "No known breaking changes
+or backward-compatibility issues."
+```
+
+Coordinate the wording of security issues that have not yet been publicly disclosed
+with the security reviewer and MSRC. Do not publish vulnerability details before their
+approved publication date. Confirm in the release work item that these sections match
+the final reviewed content and UI.
 If you are unsure about whether to include certain changes please consult with your fellow
 maintainers.
 When you're done, hit "Publish release" and mark it as the latest release.

doc/myst.yml

@@ -39,6 +39,7 @@ project:
         - "https://www.youtube.com/watch?v=jq9DcEL3cHE"
   toc:
     - file: index.md
+    - file: security.md
     - file: getting_started/README.md
       children:
         - file: getting_started/install.md

doc/security.md

@@ -0,0 +1,14 @@
+# Security
+
+Microsoft takes the security of PyRIT seriously.
+
+If you believe you have found a security vulnerability, **do not report it through a
+public GitHub issue**. Submit it privately to the
+[Microsoft Security Response Center](https://aka.ms/security.md/msrc/create-report).
+The repository's [security policy](https://github.com/microsoft/PyRIT/security/policy)
+describes alternative reporting methods, the information to include, and Microsoft's
+coordinated vulnerability disclosure policy.
+
+Review the [PyRIT release notes](https://github.com/microsoft/PyRIT/releases) for
+customer-facing security notices, known high-priority security issues, breaking
+changes, and compatibility guidance for each release.

frontend/src/components/Sidebar/Navigation.test.tsx

@@ -96,6 +96,15 @@ describe("Navigation", () => {
     expect(onOpenFeedback).toHaveBeenCalledTimes(1);
   });
 
+  it("links to the public security policy", () => {
+    renderWithProvider(<Navigation {...defaultProps} />);
+
+    expect(screen.getByRole("link", { name: "Security" })).toHaveAttribute(
+      "href",
+      "https://github.com/microsoft/PyRIT/security/policy"
+    );
+  });
+
   it("calls onNavigate with 'history' when history button is clicked", async () => {
     const user = userEvent.setup();
     const onNavigate = jest.fn();

frontend/src/components/Sidebar/Navigation.tsx

@@ -13,6 +13,7 @@ import {
   SettingsRegular,
   HistoryRegular,
   PersonFeedbackRegular,
+  OpenRegular,
   WeatherMoonRegular,
   WeatherSunnyRegular,
 } from '@fluentui/react-icons'
@@ -106,6 +107,17 @@ export default function Navigation({ currentView, onNavigate, onOpenFeedback }:
         aria-label="Feedback"
         onClick={onOpenFeedback}
       />
+      <Button
+        as="a"
+        className={styles.navButton}
+        appearance="subtle"
+        icon={<OpenRegular />}
+        title="Security"
+        aria-label="Security"
+        href="https://github.com/microsoft/PyRIT/security/policy"
+        target="_blank"
+        rel="noreferrer"
+      />
       <Menu
         checkedValues={{ [THEME_MENU_NAME]: [mode] }}
         onCheckedValueChange={handleThemeChange}