Merge branch 'nrosandich-main-patch-72f7' into 'main'

Update direction stage name to Software Supply Chain Security See merge request !10152

Merge branch 'nrosandich-main-patch-72f7' into 'main'
3b7993da · Evan Read · 17d9005e · 2bcb9b5d · 17d9005e · 3b7993da
Commit 3b7993da authored 3 months ago by Evan Read
--- a/assets/includes/engineering/govern-shared-links.md
+++ b/assets/includes/engineering/govern-shared-links.md
- Stage links
-  - Discussions and issues are located at [`gitlab-org/govern`](https://gitlab.com/gitlab-org/govern)
-  - General Slack [#s_govern](https://app.slack.com/client/T02592416/CFHGVJ06R)
-  - Social channel [#sec-section-social](https://app.slack.com/client/T02592416/C01ACJRU5PH)
-  - Engineering Slack [#sd_govern_engineering](https://app.slack.com/client/T02592416/C040C6LNANB)
-  - Govern Shared Calendar ID `gitlab.com_ed6207uel78de0j1849vjjnb3k@group.calendar.google.com`
--- a/assets/includes/engineering/software_supply_chain_security-shared-links.md
+++ b/assets/includes/engineering/software_supply_chain_security-shared-links.md
+- Stage links
+  - Discussions and issues are located at [`gitlab-org/software-supply-chain-security`](https://gitlab.com/gitlab-org/software-supply-chain-security)
+  - General Slack [#s_software-supply-chain-security](https://app.slack.com/client/T02592416/CFHGVJ06R)
+  - Social channel [#sec-section-social](https://app.slack.com/client/T02592416/C01ACJRU5PH)
+  - Engineering Slack [#sd_sscs_engineering](https://app.slack.com/client/T02592416/C040C6LNANB)
+  - Software Supply Chain Security Shared Calendar ID `gitlab.com_ed6207uel78de0j1849vjjnb3k@group.calendar.google.com`
+  - GitLab Managers: `@gitlab-org/software-supply-chain-security/managers`
--- a/content/handbook/engineering/development/sec/govern/_index.md
+++ b/content/handbook/engineering/development/sec/govern/_index.md
 ---
-title: Govern Sub-department
+title: Software Supply Chain Security Sub-department
 layout: single
 ---
-The Govern sub-department teams are the engineering teams in the [Govern Stage](/handbook/product/categories/#govern-stage) of the product.
+The Software Supply Chain Security sub-department teams are the engineering teams in the [Software Supply Chain Security Stage](https://about.gitlab.com/direction/software_supply_chain_security/) of the product.
 ## Vision
-To support GitLab's product vision through alignment with the [Govern stage](https://about.gitlab.com/direction/govern/) product direction.
+To support GitLab's product vision through alignment with the [Software Supply Chain Security stage](https://about.gitlab.com/direction/software_supply_chain_security/) product direction.
 ## Groups
@@ -15,103 +15,79 @@ To support GitLab's product vision through alignment with the [Govern stage](htt
 - [Authorization](authorization/) and [Anti-abuse](anti-abuse/)
 - [Compliance](compliance/)
 - [Pipeline Security](pipeline-security/)
- [Security Policies](security-policies/)
- [Threat Insights](threat-insights/)
 ## Priorities
-Group priorities are reviewed collaboratively with product counterparts and published on the Govern direction pages
+Group priorities are reviewed collaboratively with product counterparts and published on the Software Supply Chain Security direction pages
- [Anti-abuse](https://about.gitlab.com/direction/govern/anti-abuse/#priorities)
+- [Anti-abuse](https://about.gitlab.com/direction/software_supply_chain_security/anti-abuse/#priorities)
- [Authentication](https://about.gitlab.com/direction/govern/authentication/#priorities)
+- [Authentication](https://about.gitlab.com/direction/software_supply_chain_security/authentication/#priorities)
- [Authorization](https://about.gitlab.com/direction/govern/authorization/#priorities)
+- [Authorization](https://about.gitlab.com/direction/software_supply_chain_security/authorization/#priorities)
- [Compliance](https://about.gitlab.com/direction/govern/compliance/tactical-priorities.html#priorities)
+- [Compliance](https://about.gitlab.com/direction/software_supply_chain_security/compliance/tactical-priorities.html#priorities)
- [Pipeline Security](https://about.gitlab.com/direction/govern/pipeline_security/#priorities)
+- [Pipeline Security](https://about.gitlab.com/direction/software_supply_chain_security/pipeline_security/#priorities)
- [Security Policies](https://about.gitlab.com/direction/govern/security_policies/#priorities)
- [Threat Insights](https://about.gitlab.com/direction/govern/threat_insights/17_threat_insights_priorities.html#priorities) ([16.x](https://about.gitlab.com/direction/govern/threat_insights/16_threat_insights_priorities.html#priorities))
 ### Product Documentation Links
 - [Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)
 - [Vulnerability Pages](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/)
 - [Security scanner integration](https://docs.gitlab.com/ee/development/integrations/secure.html)
- [Secure and Govern terminology](https://docs.gitlab.com/ee/user/application_security/terminology/)
+- [Security glossary](https://docs.gitlab.com/ee/user/application_security/terminology/)
- [Govern testing priorities](https://about.gitlab.com/direction/software_supply_chain_security/)
+- [Software Supply Chain Security testing priorities](/direction/software_supply_chain_security/testing_priorities.html)
 - [Pipeline Security](https://docs.gitlab.com/ee/ci/pipelines/pipeline_security.html)
-## Sub-department development people leaders
-{{< team-by-manager-slug manager="pcalder" role="Govern" team="Engineering Manager(.*)Govern" >}}
-To contact Govern sub-department development people leaders, use the following aliases:
- GitLab: `@gitlab-org/govern/managers`
- Slack: `@s_govern_managers`
- Slack channel: `#govern-development-people-leaders`
 ## All Team Members
 ### Authentication
-{{% team-by-manager-slug manager="adil.farrukh" team="Engineer(.*)Govern:Authentication" %}}
+{{% team-by-manager-slug manager="adil.farrukh" team="Engineer(.*)Software Supply Chain Security:Authentication" %}}
 ### Authorization and Anti-abuse
-{{% team-by-manager-slug manager="jayswain" team="Engineer(.*)Govern:Authorization|Govern:Anti-Abuse" %}}
+{{% team-by-manager-slug manager="jayswain" team="Engineer(.*)Software Supply Chain Security:Authorization|Software Supply Chain Security:Anti-Abuse" %}}
 ### Compliance
-{{% team-by-manager-slug manager="nrosandich" team="Engineer(.*)Govern:Compliance" %}}
+{{% team-by-manager-slug manager="nrosandich" team="Engineer(.*)Software Supply Chain Security:Compliance" %}}
 ### Pipeline Security
-{{< team-by-manager-slug manager="scott-hampton" team="Engineer(.+)Govern:Pipeline Security" >}}
+{{< team-by-manager-slug manager="scott-hampton" team="Engineer(.+)Software Supply Chain Security:Pipeline Security" >}}
-### Security Policies
-{{% team-by-manager-slug manager="maciejparuszewski" team="Engineer(.*)Govern:Security Policies" %}}
-### Threat Insights
-{{% team-by-manager-slug manager="nmccorrison" team="Engineer(.*)Govern:Threat Insights" %}}
-{{% team-by-manager-slug manager="ryaanwells" team="end Engineer(.*)Govern:Threat Insights" %}}
 ## Stable Counterparts
 The following members of other functional teams are our stable counterparts:
-{{% stable-counterparts role="Govern" other-manager-roles="Engineering Manager(.*)Govern:(.*)|Director of Engineering(.*)Govern" %}}
+{{% stable-counterparts role="Software Supply Chain Security" other-manager-roles="Engineering Manager(.*)Software Supply Chain Security:(.*)|Director of Engineering(.*)Software Supply Chain Security" %}}
-## Govern staff meeting
+## Software Supply Chain Security staff meeting
-The Govern stage engineering department leaders meet weekly to discuss stage and group topics in the `Govern staff meeting`. This meeting is open to all team members and is published on the Govern stage calendar.
+The Software Supply Chain Security stage engineering department leaders meet weekly to discuss stage and group topics in the `Software Supply Chain Security staff meeting`. This meeting is open to all team members and is published on the Software Supply Chain Security stage calendar.
 Meetings have an agenda and are async-first, where the aim is to resolve discussions async and leave time in the meeting to deep dive into topics that require more discussion.
-We use the [Govern Sub-department Board](https://gitlab.com/gitlab-com/govern-sub-department/-/boards/4833026) to better organize our discussions.
+We use the [Software Supply Chain Security Sub-department Board](https://gitlab.com/gitlab-com/software_supply_chain_security-sub-department/-/boards/4833026) to better organize our discussions.
 ### Weekly updates
-The Govern development teams provide [weekly status updates](https://gitlab.com/groups/gitlab-com/-/epics/2126) using an issue template and CI scheduled job.
+The Software Supply Chain Security development teams provide [weekly status updates](https://gitlab.com/groups/gitlab-com/-/epics/2126) using an issue template and CI scheduled job.
-As priorities change, engineering managers update the [template](https://gitlab.com/gitlab-com/govern-sub-department/-/blob/main/.gitlab/issue_templates/govern_stage_weekly_update.md) to include areas of interest such as priorities, opportunities, risks, and security and availability concerns. The updates are GitLab internal.
+As priorities change, engineering managers update the [template](https://gitlab.com/gitlab-com/software_supply_chain_security-sub-department/-/blob/main/.gitlab/issue_templates/sscs_stage_weekly_update.md) to include areas of interest such as priorities, opportunities, risks, and security and availability concerns. The updates are GitLab internal.
 ### Quarterly review updates
-Every quarter, an engineering manager for each group in the Govern Sub-department prepares the quarterly review update using the issue template and records approximately 5 minutes to summarize the last quarter from the engineering perspective and present a high-level plan for the group for the next one to respond to quarterly Product strategy and explain our goals for next quarter.
+Every quarter, an engineering manager for each group in the Software Supply Chain Security Sub-department prepares the quarterly review update using the issue template and records approximately 5 minutes to summarize the last quarter from the engineering perspective and present a high-level plan for the group for the next one to respond to quarterly Product strategy and explain our goals for next quarter.
-We aim to foster collaboration and communication between engineering managers in the Govern Sub-department, align groups on product priorities for the next quarter, and celebrate our successes together.
+We aim to foster collaboration and communication between engineering managers in the Software Supply Chain Security Sub-department, align groups on product priorities for the next quarter, and celebrate our successes together.
-Quarterly review update template can be found [here](https://gitlab.com/gitlab-com/govern-sub-department/-/blob/main/.gitlab/issue_templates/govern_stage_quarterly_review.md)).
+Quarterly review update template can be found [here](https://gitlab.com/gitlab-com/software_supply_chain_security-sub-department/-/blob/main/.gitlab/issue_templates/sscs_stage_quarterly_review.md)).
 ### OKR planning
-Our OKRs are a mixture of top down, aligned with Company-wide, Product, or Engineering Division OKRs, and bottom up engineering-led initiatives driven by our team members in Govern. Any team member can propose an OKR for Govern by creating a [proposal issue](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?sort=created_date&state=opened&or%5Blabel_name%5D%5B%5D=Sub-Department%3A%3AGovern&or%5Blabel_name%5D%5B%5D=devops%3A%3Agovern&search=Govern%20%28proposal%29&first_page_size=100) in our internal OKR project. The issue can be used to collaborate and discuss the proposal. When we are ready to commit, we can create or align to an existing Objective, and add specific key results to track through the quarter.
+Our OKRs are a mixture of top down, aligned with Company-wide, Product, or Engineering Division OKRs, and bottom up engineering-led initiatives driven by our team members in Software Supply Chain Security. Any team member can propose an OKR for Software Supply Chain Security by creating a [proposal issue](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/) in our internal OKR project. The issue can be used to collaborate and discuss the proposal. When we are ready to commit, we can create or align to an existing Objective, and add specific key results to track through the quarter.
 Labels:
- `Sub-Department::Govern` - for top-level sub-department Objectives.
+- `Sub-Department::software supply chain security` - for top-level sub-department Objectives.
- `devops::govern` - for Objectives and key results for the stage, and stage groups
+- `devops::software supply chain security` - for Objectives and key results for the stage, and stage groups
 - `group::` - for Objectives and key results for a specific group
 Each Objective and Key Result should have an assignee who is DRI for providing status updates throughout the quarter. Regular updates are preferred. At a minimum these should be updated
@@ -123,14 +99,14 @@ OKRs can be changed or closed during the quarter if they are completed, or as ou
 ### PTO
-To support our teams, and commitments made to internal and external customers, team members in Govern are encouraged to create a PTO issue before going on leave lasting a week or longer.
+To support our teams, and commitments made to internal and external customers, team members in Software Supply Chain Security are encouraged to create a PTO issue before going on leave lasting a week or longer.
 The issue provides a place to discuss and document coverage for any work in progress, or projects where the team member is the directly responsible individual (DRI), and support the [Paid Time Off at GitLab](/handbook/people-group/paid-time-off/) policy.
 We use an internal issue tracker as team member PTO is not public information, and a PTO template
- [PTO issue list](https://gitlab.com/gitlab-com/govern-sub-department/-/issues/?sort=weight_desc&state=opened&label_name%5B%5D=PTO&first_page_size=20)
+- [PTO issue list](https://gitlab.com/gitlab-com/software_supply_chain_security-sub-department/-/issues/?sort=weight_desc&state=opened&label_name%5B%5D=PTO&first_page_size=20)
- [New PTO issue template](https://gitlab.com/gitlab-com/govern-sub-department/-/issues/new?issuable_template=ooo_template)
+- [New PTO issue template](https://gitlab.com/gitlab-com/software_supply_chain_security-sub-department/-/issues/new?issuable_template=ooo_template)
 When a team-member takes some time off, it is important that their work is still being followed up on if needed. We want to make sure that any MR that lands in staging and production environments while we are out gets proper attention and is verified by a counterpart. Therefore, when getting close to our time-off period, we should do the following:
@@ -141,7 +117,7 @@ Keep in mind that, while we strongly recommend following this process when takin
 #### Engineering Leadership - PTO or unavailable
-Team members should contact any Govern Engineering Manager by mentioning in `#sd_govern_engineering` or `#govern-development-people-leaders` if they need management support for a problem that arises, such as a production incident or feature change lock, when their direct manager is not available. The Govern manager can provide guidance and coordination to ensure that the team member receives the appropriate help.
+Team members should contact any Software Supply Chain Security Engineering Manager by mentioning in `#sd_sscs_engineering` or `#sscs-development-people-leaders` if they need management support for a problem that arises, such as a production incident or feature change lock, when their direct manager is not available. The Software Supply Chain Security manager can provide guidance and coordination to ensure that the team member receives the appropriate help.
 Some people management tasks, including [Workday](/handbook/people-group/workday-guide) and [Navan Expense](/handbook/business-technology/enterprise-applications/guides/navan-expense-guide), may require for escalation or delegation.
@@ -160,36 +136,31 @@ Because we have a wide range of domains to cover, it requires a lot of different
 ## Everyone can contribute
-At GitLab our goal is that [everyone can contribute](/handbook/company/mission/#contribute-to-gitlab-application). This applies to GitLab team members and the wider community through community contributions. We welcome contributions to any and all features, but recognize that first time contributors may prefer to start with smaller features. To support this we maintain a list of `quick wins` that may be more suitable for first time contributors, and contributors new to the domains in Govern.
+At GitLab our goal is that [everyone can contribute](/handbook/company/mission/#contribute-to-gitlab-application). This applies to GitLab team members and the wider community through community contributions. We welcome contributions to any and all features, but recognize that first time contributors may prefer to start with smaller features. To support this we maintain a list of `quick wins` that may be more suitable for first time contributors, and contributors new to the domains in Software Supply Chain Security.
- [Quick wins](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=quick%20win&label_name%5B%5D=devops%3A%3Agovern&first_page_size=100)
+- [Quick wins](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=quick%20win&label_name%5B%5D=devops%3A%3Asoftware%20supply%20chain%20security&first_page_size=20)
 If the contributor needs an EE license, we can point towards the [Contributing to the GitLab Enterprise Edition (EE)](/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributing-to-the-gitlab-enterprise-edition-ee) section on the Community contributors workflows page.
 ## Testing
-During the planning phase of a milestone, the EM for each group will create a new issue using the template in [epic](https://gitlab.com/groups/gitlab-org/quality/quality-engineering/-/epics/70), for any major new features and tag Software Engineer in Test from Govern. SETs from Test Engineering and EMs can periodically review/discuss the list of open issues, and add appropriate priority labels.
+During the planning phase of a milestone, the EM for each group will create a new issue using the template in [epic](https://gitlab.com/groups/gitlab-org/quality/quality-engineering/-/epics/70), for any major new features and tag Software Engineer in Test from Software Supply Chain Security. SETs from Test Engineering and EMs can periodically review/discuss the list of open issues, and add appropriate priority labels.
 The intent of [shifting left and testing at the right level](https://docs.gitlab.com/ee/development/testing_guide/testing_levels.html#how-to-test-at-the-correct-level) is that teams are responsible for testing and to have engineers doing the feature coverage reviews and adding specs or E2E test as needed. The reason for including the SET is to give oversight across the groups and provide guidance/support. If the SET has capacity then they can contribute as needed, using the priority labels, but this is not the expectation.
 ## Metrics
 {{< tableau height="600px" toolbar="hidden" src="https://us-west-2b.online.tableau.com/t/gitlabpublic/views/TopEngineeringMetrics/TopEngineeringMetricsDashboard" >}}
-  {{< tableau/filters "STAGE_LABEL"="govern" >}}
+  {{< tableau/filters "STAGE_LABEL"="software_supply_chain_security" >}}
 {{< /tableau >}}
 {{< tableau height="600px" src="https://us-west-2b.online.tableau.com/t/gitlabpublic/views/MergeRequestMetrics/OverallMRsbyType_1" >}}
-  {{< tableau/filters "STAGE_LABEL"="govern" >}}
+  {{< tableau/filters "STAGE_LABEL"="software_supply_chain_security" >}}
 {{< /tableau >}}
 ## Links and resources
-{{% include "includes/engineering/govern-shared-links.md" %}}
+{{% include "includes/engineering/software_supply_chain_security-shared-links.md" %}}
- Group [#g_govern_security_policies](https://gitlab.slack.com/archives/CU9V380HW)
- Group [#g_govern_threat_insights](https://gitlab.slack.com/archives/CV09DAXEW)
- Group [#g_govern_compliance](https://gitlab.slack.com/messages/CN7C8029H)
- [Software Supply Chain Security working group](/handbook/company/working-groups/software-supply-chain-security/)
 ### Technical Documentation Links

--- a/content/handbook/engineering/development/sec/govern/authentication.md
+++ b/content/handbook/engineering/development/sec/govern/authentication.md
@@ -296,7 +296,7 @@ The following people are permanent members of the group:
 ### Links and resources {#links}
-{{% include "includes/engineering/govern-shared-links.md" %}}
+{{% include "includes/engineering/software_supply_chain_security-shared-links.md" %}}
 - [Milestone retrospectives](https://gitlab.com/gl-retrospectives/govern/authentication/-/issues/53)
 - Our Slack channels

--- a/content/handbook/engineering/development/sec/govern/compliance.md
+++ b/content/handbook/engineering/development/sec/govern/compliance.md
@@ -8,11 +8,11 @@ The Compliance group's mission is to provide visibility into an organizations co
 ## What we work on
- We use the [Group Direction page](https://about.gitlab.com/direction/govern/compliance/) to describe our high-level goals and direction for our group.
+- We use the [Group Direction page](https://about.gitlab.com/direction/software_supply_chain_security/compliance/) to describe our high-level goals and direction for our group.
- From the high-level goals and direction we filter down to a prioritised list of Epics, we try to keep updated in our [Tactical Priorities](https://about.gitlab.com/direction/govern/compliance/tactical-priorities.html)
+- From the high-level goals and direction we filter down to a prioritised list of Epics, we try to keep updated in our [Tactical Priorities](https://about.gitlab.com/direction/software_supply_chain_security/compliance/tactical-priorities.html)
- This prioritised list we then use when planning each Milestone. Each Milestone will have its own Issue in our [Planning Epic](https://gitlab.com/groups/gitlab-org/govern/compliance/-/epics/2)
+- This prioritised list we then use when planning each Milestone. Each Milestone will have its own Issue in our [Planning Epic](https://gitlab.com/groups/gitlab-org/software-supply-chain-security/compliance/-/epics/2)
  - In addition to using the high-level goals and direction as an input to planning Milestones, the Compliance Product Manager considers input from Sales, customers, and internal stakeholders (dogfooding) to decide on the priority for the issues added to each Milestone.
- We also use [OKRs](/handbook/company/okrs/) to help prioritise strategic initiatives within the group. We use Issues for planning and collate them in our [OKR Epic](https://gitlab.com/groups/gitlab-org/govern/compliance/-/epics/4)
+- We also use [OKRs](/handbook/company/okrs/) to help prioritise strategic initiatives within the group. We use Issues for planning and collate them in our [OKR Epic](https://gitlab.com/groups/gitlab-org/software-supply-chain-security/compliance/-/epics/4)
 ## Top Priorities FY25
@@ -26,7 +26,7 @@ The Compliance group's mission is to provide visibility into an organizations co
 ## How we work
 - In accordance with our [GitLab values](/handbook/values/).
- Transparently: nearly everything is public, we record/livestream meetings whenever possible (see [links](/handbook/engineering/development/sec/govern/compliance/#links))
+- Transparently: nearly everything is public, we record/livestream meetings whenever possible (see [links](#links))
 - We get a chance to work on the things we want to work on.
 - Everyone can contribute; no silos.
  - The goal is to have product give engineering and design the opportunity to be involved with direction and issue definition from the very beginning.
@@ -40,7 +40,7 @@ Because this group works on components of the application that have a [far-reach
 1. To build more institutional knowledge across the team we try to assign our merge requests to another Compliance team member for first review.
 1. Compliance merge requests use feature flags where it makes sense to minimise impact. We follow the [Feature Flag Lifecycle](/handbook/product-development-flow/feature-flag-lifecycle/) as closely as possible
 1. If a feature flag is used then a feature flag [rollout plan](/handbook/engineering/development/processes/rollout-plans/) will be created. Support (`#support_gitlab-com`) will also be [notified](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md?plain=1#L94) if necessary.
-1. Compliance related merge requests require a review by a [Compliance Engineer](https://gitlab.com/groups/gitlab-org/govern/compliance/engineering/-/group_members?with_inherited_permissions=exclude). This is guarded by using the `CODEOWNERS` feature of GitLab.
+1. Compliance related merge requests require a review by a [Compliance Engineer](https://gitlab.com/groups/gitlab-org/software-supply-chain-security/compliance/engineering/-/group_members?with_inherited_permissions=exclude). This is guarded by using the `CODEOWNERS` feature of GitLab.
 ### Working on ad hoc work and questions
@@ -124,7 +124,7 @@ We plan in monthly cycles in accordance with our [Product Development Timeline](
 ### Pre-planning
- By the 4th, Product should have created a planning issue for their group in the [Compliance project](https://gitlab.com/gitlab-org/govern/compliance/general/-/issues) for the coming release using the [template](https://gitlab.com/gitlab-org/govern/compliance/general/-/blob/main/.gitlab/issue_templates/planning_issue.md).
+- By the 4th, Product should have created a planning issue for their group in the [Compliance project](https://gitlab.com/gitlab-org/software-supply-chain-security/compliance/general/-/issues) for the coming release using the [template](https://gitlab.com/gitlab-org/software-supply-chain-security/compliance/general/-/blob/main/.gitlab/issue_templates/planning_issue.md).
 - The Complaince [quad](/handbook/engineering/infrastructure/test-platform/quad-planning/) will add a tentative plan for the release, outlining the highest priority issues within each of their respective areas.
 - We prioritize using the [cross-functional prioritization](/handbook/product/product-processes/cross-functional-prioritization/). The Product Manager will prioritize `type::feature` issues, the Engineering Manager will prioritize `type::maintenance` issues, and the Quality Manager will prioritize `type::bug` issues.
 - Pre-planning is completed asynchronously by Product, Engineering, Quality and Design on the issue, this is to identify any unknowns or questions that need to be answered and resolved prior to final planning.
@@ -280,7 +280,7 @@ The following is an example of an implementation approach from [https://gitlab.c
 ~documentation
 1. Update docs page eg https://docs.gitlab.com/ee/administration/audit_events.html
-1. Update the GraphQL examples https://gitlab.com/gitlab-org/govern/compliance/graphql-example-requests
+1. Update the GraphQL examples <https://gitlab.com/gitlab-org/software-supply-chain-security/compliance/engineering/graphql-example-requests>
 ~quality
@@ -289,7 +289,7 @@ The following is an example of an implementation approach from [https://gitlab.c
 ```
 The [DRI](/handbook/people-group/directly-responsible-individuals/) will ping a relevant counterpart (Quality, UX, etc) and domain expert (database, backend, frontend) before moving the issue to `workflow::scheduling`. This gives the domain expert the opportunity to approve the implementation plan or raise any potential pitfalls or concerns before work begins.
-For domain expert review of development implementation plan, in case of trivial changes, the approval can be solicited from any of the relevant compliance development team members. Do try to find a person who has context around the topic. In case of non-trivial changes, opinions from the whole relevant compliance backend or frontend or both team members should be solicited by tagging respective group (`@gitlab-org/govern/compliance/engineering`) in the issue's comment. Deciding whether the implementation is trivial or non-trivial depends on the discretion of DRI and the initial domain expert asked for review.
+For domain expert review of development implementation plan, in case of trivial changes, the approval can be solicited from any of the relevant compliance development team members. Do try to find a person who has context around the topic. In case of non-trivial changes, opinions from the whole relevant compliance backend or frontend or both team members should be solicited by tagging respective group (`@gitlab-org/software-supply-chain-security/compliance/engineering`) in the issue's comment. Deciding whether the implementation is trivial or non-trivial depends on the discretion of DRI and the initial domain expert asked for review.
 Once an issue has been estimated, it can then be moved to `workflow::scheduling` to be assigned a milestone before finally being `workflow::ready for development`.
@@ -391,7 +391,7 @@ Great job! 🎉 Your PTO events will be synced to Compliance Group Shared Calend
 ## Group News
 The EM will usually create a general update for the group on what is happening within the company and within the group on a weekly basis.
-This update currently takes the form of an issue within the [compliance update Epic](https://gitlab.com/groups/gitlab-org/govern/compliance/-/epics/3)
+This update currently takes the form of an issue within the [compliance update Epic](https://gitlab.com/groups/gitlab-org/software-supply-chain-security/compliance/-/epics/3)
 The Compliance EM also contributes to issues in the [Software Supply Chain Security stage weekly updates](https://gitlab.com/groups/gitlab-com/-/epics/2126) epic.
@@ -426,11 +426,11 @@ The following people are permanent members of the group:
 ## Links and resources {#links}
 - GitLab
-  - [gitlab-org/govern/compliance](https://gitlab.com/gitlab-org/govern/compliance)
+  - [gitlab-org/software-supply-chain-security/compliance](https://gitlab.com/gitlab-org/software-supply-chain-security/compliance)
-  - [General issues and discussions](https://gitlab.com/gitlab-org/govern/compliance/general/-/issues)
+  - [General issues and discussions](https://gitlab.com/gitlab-org/software-supply-chain-security/compliance/general/-/issues)
-  - [Engineering issues and discussions](https://gitlab.com/gitlab-org/govern/compliance/engineering)
+  - [Engineering issues and discussions](https://gitlab.com/gitlab-org/software-supply-chain-security/compliance/engineering)
-  - Compliance alias: `@gitlab-org/govern/compliance`
+  - Compliance alias: `@gitlab-org/software-supply-chain-security/compliance`
-  - Compliance engineering alias: `@gitlab-org/govern/compliance/engineering`
+  - Compliance engineering alias: `@gitlab-org/software-supply-chain-security/compliance/engineering`
  - [Milestone retrospectives](https://gitlab.com/gl-retrospectives/govern/compliance/-/issues)
  - Issue boards
    - [Build board](https://gitlab.com/groups/gitlab-org/-/boards/1305010)
@@ -447,4 +447,4 @@ The following people are permanent members of the group:
  - [Product](https://www.youtube.com/playlist?list=PL05JrBw4t0KqWds1BN41IJxLd1AvpZxGu)
  - [Meetings](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq7_yBKIYHi8qvCWeU0Q3yH)
-{{% include "includes/engineering/govern-shared-links.md" %}}
+{{% include "includes/engineering/software_supply_chain_security-shared-links.md" %}}