docs: add DevSecOps workshop guidance (DS series) - Aug 2026 update (#1453)

Author: tylchan

src/react/docs/workshop-guidance/devsecops/DS_001.md

@@ -0,0 +1,22 @@
+# Define ownership and governance model for DevSecOps privileged groups
+
+**Implementation Effort:** Medium – Inventorying privileged GitHub and Azure DevOps groups, assigning owners, and standing up access reviews and access packages spans identity engineering and the DevSecOps platform team.
+**User Impact:** Low – Group owners and administrators run the reviews and expiration policies; everyday developers are not prompted or affected.
+**Lifecycle Stage:** Govern
+
+## Overview
+
+Establish a governance model for DevSecOps privileged groups by using Microsoft Entra access reviews, entitlement management, ownership, and expiration policies. Privileged security groups in DevSecOps environments — such as groups that grant organization-owner access to GitHub, project-collection administrator rights in Azure DevOps, or pipeline administrator roles — tend to grow over time and rarely shrink on their own. Members are added to meet immediate project needs, but removal is inconsistent because no formal process governs who reviews the membership, how often, or what happens when access is no longer justified.
+
+Make ownership boundaries explicit so this control does not float between teams: this task lives in the DevOps Identity and Access area because it governs who can administer source platforms and pipelines. Identity engineering owns Microsoft Entra policy patterns and enforcement guardrails, while the DevSecOps platform owner is accountable for inventorying the privileged groups used by GitHub and Azure DevOps, assigning business owners for each group, and ensuring review outcomes are acted on. Keep role governance here — alongside privileged access policies and the periodic reduction of administrative permissions — and rely on Conditional Access enforcement for developer platform access and on program-level security dashboards and metrics reporting for monitoring and KPI reporting.
+
+Microsoft Entra ID provides the tools to bring discipline to this problem. Prerequisite: Microsoft Entra ID P2 provides Access Reviews and Entitlement Management, with enhanced controls available through the Microsoft Entra ID Governance add-on. Access reviews enable recurring, scheduled evaluations of group membership where designated reviewers — group owners, managers, or the members themselves — must attest that each assignment is still warranted. Entitlement management bundles privileged group memberships into access packages with built-in approval workflows, time-limited assignments, and automatic expiration. Access packages support configurable assignment durations (e.g., 90-day access with optional renewal), enforcing time-bound DevOps privileges. Together, these capabilities ensure that membership in a privileged DevSecOps group is never indefinite by default and is always traceable to a documented business justification.
+
+Without governance controls, organizations cannot answer basic questions that auditors and incident responders need: who approved this person's access, when was it last reviewed, and is it still necessary. Establishing lifecycle governance for privileged DevSecOps groups means every membership has an owner, a review cadence, and an expiration policy — turning static, forgotten group assignments into actively managed, continuously validated entitlements that align with Zero Trust expectations. This directly advances Use least privilege access by keeping privileged membership minimal, owned, and time-bound, and it supports Assume breach by making every entitlement continuously reviewable and revocable.
+
+## Reference
+
+* [What is entitlement management?](https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview)
+* [Create an access review of groups and applications](https://learn.microsoft.com/en-us/entra/id-governance/create-access-review)
+* [Synchronizing a team with an identity provider group](https://docs.github.com/en/enterprise-cloud@latest/organizations/organizing-members-into-teams/synchronizing-a-team-with-an-identity-provider-group)
+* [About permissions and groups](https://learn.microsoft.com/en-us/azure/devops/organizations/security/about-permissions?view=azure-devops)

src/react/docs/workshop-guidance/devsecops/DS_002.md

@@ -0,0 +1,23 @@
+# Define developer platform roles and access model
+
+**Implementation Effort:** Medium – Designing a unified role model across GitHub, Azure DevOps, and Microsoft Entra ID takes several steps and coordination among platform, security, and identity teams.
+**User Impact:** Medium – Developers who held broad roles or shared accounts move to narrower, per-identity access, so the affected subset needs notice about their new permissions.
+**Lifecycle Stage:** Govern
+
+## Overview
+
+Design a unified permissions and access model across GitHub, Azure DevOps, and Microsoft Entra ID so every human and workload identity has only the minimum access required. Without a deliberate model, organizations accumulate overly broad roles and shared service accounts that allow a single compromised credential to move laterally across repositories, pipelines, and cloud subscriptions.
+
+In GitHub, use teams and repository roles for baseline access. Layer organization rulesets, branch protection, CODEOWNERS, and required pull-request reviews to prevent unreviewed merges. Configure environment protection rules with required reviewers and restrict bypass permissions.
+
+In Azure DevOps, layer project-level security groups, branch-level permissions, and pipeline-scoped service connections. Separate approval workflows for release paths and use scoped credentials instead of shared accounts to prevent lateral movement.
+
+Back both platforms with Microsoft Entra ID to govern sign-in, multifactor authentication, and access reviews. For GitHub organizations that rely on personal accounts plus SAML SSO, Conditional Access does not cover every Git operation or PAT use. Pair Entra controls with GitHub token policies, SSO enforcement, and IP allow lists to close those gaps.
+
+Every pipeline, service connection, and token is a potential pivot point. An intentional permissions model ensures that reading code, merging changes, and deploying to production are distinct privilege boundaries — not capabilities bundled into a single identity. This model embodies Use least privilege access by granting each identity only the minimum it requires, and it reinforces Verify explicitly by backing every sign-in with Microsoft Entra authentication, multifactor authentication, and access reviews.
+
+## Reference
+
+* [Secure DevOps environments for Zero Trust](https://learn.microsoft.com/en-us/security/zero-trust/develop/secure-devops-environments-zero-trust)
+* [Roles in a GitHub organization](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)
+* [Default permissions and access for Azure DevOps](https://learn.microsoft.com/en-us/azure/devops/organizations/security/permissions-access)

src/react/docs/workshop-guidance/devsecops/DS_004.md

@@ -0,0 +1,24 @@
+# Discover and remediate ungoverned developer platform accounts
+
+**Implementation Effort:** Medium – Auditing every GitHub and Azure DevOps roster, then migrating, converting, or removing accounts, is a multi-step effort coordinated with platform and identity owners.
+**User Impact:** Medium – People behind orphaned or external accounts must move to governed identities or lose access, so the affected subset needs advance communication.
+**Lifecycle Stage:** Govern
+
+## Overview
+
+Audit the membership rosters of every GitHub organization and Azure DevOps organization to identify accounts that do not map to a Microsoft Entra ID principal, then migrate, convert, or remove them.
+
+Start by auditing your accounts: In Azure DevOps, compare the users list against your connected Microsoft Entra ID tenant. In GitHub Enterprise Cloud, use the audit log and Microsoft Entra ID SCIM provisioning logs to identify accounts created outside the governed identity flow. Once identified, evaluate each account individually. Some should be migrated to Enterprise Managed Users for human access or replaced with workload identities — GitHub Apps for GitHub automation and Microsoft Entra service principals or managed identities for Azure DevOps and Azure deployments — and others should be removed entirely.
+
+Even after an organization integrates its developer platforms with Microsoft Entra ID, legacy local accounts and standalone identities often persist. These are accounts created before the Microsoft Entra ID integration, service accounts with platform-native credentials, bot accounts that were never linked to a managed identity, or personal GitHub accounts that developers linked to the organization before Enterprise Managed Users was adopted. Each of these accounts operates outside the enterprise identity perimeter. They do not honor Conditional Access policies, cannot be subject to access reviews, and will not be disabled when an employee offboards through HR-driven lifecycle workflows. For threat actors, these orphaned accounts are high-value targets because compromising one yields access that is invisible to the organization's security monitoring.
+
+Partner and external collaboration is a common source of ungoverned accounts and deserves explicit attention. When a partner organization contributes to your code, the answer is not to add the partner's personal account as an outside collaborator — that creates exactly the kind of identity this task exists to remove. Instead, bring external contributors in through governed external identity: Microsoft Entra External ID B2B collaboration so the guest is represented by an Entra principal in your tenant, or Enterprise Managed Users where the platform supports managed guest collaborators. Governed external access can then be subject to Conditional Access, time-bound through access reviews and Privileged Identity Management, scoped to least privilege on only the repositories the partner needs, and automatically de-provisioned when the engagement ends. Treat any external contributor who is not represented by a governed Entra identity as an account to remediate, the same as an internal orphaned account.
+
+Leaving unmanaged accounts in place undermines every upstream identity investment. Conditional Access, MFA, and PIM are only effective when there is no path around them.
+
+## Reference
+
+* [Reviewing the audit log for your organization](https://docs.github.com/en/organizations/keeping-your-organization-secure/reviewing-the-audit-log-for-your-organization)
+* [About SCIM for organizations](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations)
+* [B2B collaboration overview](https://learn.microsoft.com/en-us/entra/external-id/what-is-b2b)
+* [Access, export, and filter audit logs for Azure DevOps](https://learn.microsoft.com/en-us/azure/devops/organizations/audit/azure-devops-auditing)

src/react/docs/workshop-guidance/devsecops/DS_005.md

@@ -0,0 +1,23 @@
+# Integrate DevOps platforms with Microsoft Entra ID
+
+**Implementation Effort:** Medium – Connecting GitHub EMU and Azure DevOps to Entra ID, setting up SCIM provisioning, and planning the account cutover involves several steps across identity and platform teams.
+**User Impact:** Medium – Developers sign in through Entra ID and, under EMU, receive replacement accounts, so affected users must be prepared for the change.
+**Lifecycle Stage:** Govern
+
+## Overview
+
+Integrate GitHub Enterprise Cloud and Azure DevOps with Microsoft Entra ID so that sign-in, lifecycle management, and Conditional Access flow through a single identity control plane.
+
+For GitHub Enterprise Cloud, connect Microsoft Entra ID as the identity provider. Enterprise Managed Users (EMU) is the recommended approach: every GitHub account is fully governed by the enterprise identity provider, eliminating shadow accounts. With EMU, use OIDC for authentication when integrating with Entra ID — OIDC is required for GitHub's Conditional Access Policy (CAP) validation. SAML SSO remains available for organizations that have not adopted EMU.
+
+Use Microsoft Entra ID SCIM-based provisioning to automate the GitHub user lifecycle. When an employee is assigned to the GitHub EMU enterprise application in Entra ID, an account is created automatically. When they are removed, access is revoked during the next SCIM sync cycle. For immediate deprovisioning, administrators can trigger on-demand provisioning from the Entra admin center. Plan carefully before adopting EMU: existing GitHub user accounts are replaced, and existing commits retain their original author attribution.
+
+Azure DevOps uses native Microsoft Entra ID-backed sign-in rather than SAML. User lifecycle is managed through Entra ID group membership and direct assignment rather than SCIM. When a user is removed from the connected tenant or governing group, interactive access is blocked immediately. Remaining tokens or sessions expire on their normal schedule, so pair deprovisioning with token governance and session awareness.
+
+Without Entra ID integration, developers can authenticate with platform-local credentials outside the enterprise identity perimeter. The organization loses the ability to enforce Conditional Access, require multifactor authentication, detect risky sign-ins, or automatically deprovision departing users. This integration is a prerequisite for nearly every other DevSecOps security control. By routing every sign-in through a single identity control plane, this integration is foundational to Verify explicitly, ensuring each authentication is evaluated against Conditional Access, multifactor authentication, and sign-in risk signals.
+
+## Reference
+
+* [Connect your organization to Microsoft Entra ID](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/connect-organization-to-azure-ad?view=azure-devops)
+* [About Enterprise Managed Users](https://docs.github.com/en/enterprise-cloud@latest/admin/concepts/identity-and-access-management/enterprise-managed-users)
+* [Configuring authentication for Enterprise Managed Users](https://docs.github.com/en/enterprise-cloud@latest/admin/managing-iam/configuring-authentication-for-enterprise-managed-users)

src/react/docs/workshop-guidance/devsecops/DS_006.md

@@ -0,0 +1,24 @@
+# Define developer access policies using Privileged Identity Management
+
+**Implementation Effort:** Medium – Scoping PIM eligibility to GitHub and Azure DevOps admin roles builds on existing Entra governance but requires identity and platform teams to configure and test activation policies.
+**User Impact:** Medium – Privileged users must request just-in-time activation before administering the platforms, so a subset of admins are prompted rather than holding standing access.
+**Lifecycle Stage:** Govern
+
+## Overview
+
+Use Microsoft Entra Privileged Identity Management to replace standing privileged access on developer platforms with just-in-time, time-bounded role activation. Developers and administrators are assigned eligible roles rather than active ones.
+
+Apply PIM policies to the Microsoft Entra roles and groups that govern GitHub and Azure DevOps administration rather than re-implementing tenant-wide PIM policy. Build on your Identity pillar's core PIM governance to scope these policies to DevOps-specific roles and groups.
+
+When privileged access is needed, the user requests activation for a limited duration and must satisfy governance controls such as multi-factor authentication, business justification, and optionally manager approval. Activation duration is configurable from 1 to 24 hours, with administrators setting the ceiling per role, after which privileges automatically expire. Every elevation request is logged with full context — who requested it, why, when, and for how long — giving security operations a clear audit trail for compliance and incident investigation.
+
+PIM for Groups, part of Microsoft Entra ID Governance, can make membership in Microsoft Entra groups eligible rather than permanent for groups that govern GitHub or Azure DevOps access. GitHub team synchronization with PIM for Groups is not officially documented by Microsoft and should be treated as a custom pattern with unpredictable latency. For GitHub organizations using team synchronization with Microsoft Entra groups, PIM for Groups can be used but introduces synchronization delay — often 15 to 60 minutes — between activation and GitHub team membership updates. Validate behavior in your environment, document the expected delay, and do not rely on this pattern for emergency access or tightly time-bound operations. For those scenarios, prefer direct GitHub role assignments with manual approval workflows instead of relying on group synchronization. In Azure DevOps, the same group-based approach can be used where Microsoft Entra groups govern project or administrative access.
+
+Privileged roles on developer platforms — organization owners, repository administrators, pipeline administrators — carry outsized risk because they can modify security settings, disable branch protections, access secrets, and alter build definitions. When these roles are permanently assigned, every account that holds one becomes a high-value target around the clock. A threat actor who compromises a standing org-owner account gains immediate, unrestricted control over the entire development environment without needing to escalate privileges or bypass additional controls. The longer a privilege is active, the larger the window of exposure. Organizations that rely on standing admin assignments instead of PIM cannot demonstrate that privileged access is controlled, time-bound, and auditable — leaving them exposed to insider threats, credential theft, and compliance gaps that a Zero Trust posture is designed to eliminate. Just-in-time activation is a direct application of Use least privilege access, and by removing standing administrative rights it supports Assume breach by shrinking the window in which a compromised account could be abused.
+
+## Reference
+
+* [Configure PIM for Groups](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/concept-pim-for-groups)
+* [Synchronizing a team with an identity provider group](https://docs.github.com/en/enterprise-cloud@latest/organizations/organizing-members-into-teams/synchronizing-a-team-with-an-identity-provider-group)
+* [Set up PIM access in Azure DevOps](https://devblogs.microsoft.com/devops/set-up-pim-access-in-azure-devops/)
+* [About permissions and groups](https://learn.microsoft.com/en-us/azure/devops/organizations/security/about-permissions?view=azure-devops)