Establish secure developer environment standards
Implementation Effort: Medium – Defining approved tools, secret handling, commit integrity, and workstation requirements and aligning them across pillars requires cross-team coordination. User Impact: Medium – Developers must adopt the new environment standards, including SAW or PAW requirements for those who can reach production, so a subset of engineers is affected. Lifecycle Stage: Code
Overview
Establish and enforce a secure developer environment standard that covers approved tools, secret handling, commit integrity, workstation isolation, and extension governance. Align the standard to Microsoft Security Development Lifecycle practice 6, "Secure the engineering environment."
General endpoint security — disk encryption, EDR, OS patching — is addressed by the Devices pillar of a Zero Trust assessment. Developer workstations introduce additional attack surface: IDE extensions, local secret handling, Git configuration, and development toolchains. These SDLC-specific risks require targeted controls that complement the organization's broader device security posture.
Scope the workstation-assurance requirement by the access a role can reach, not only by whether it holds a formally privileged directory role. Require a Secure Admin Workstation or Privileged Access Workstation for anyone who can deploy to production, approve or merge to protected branches, hold deployment-identity credentials, or otherwise reach production systems and customer data. In the Microsoft IT model, a developer cannot reach production without a SAW even when they hold no classic administrator role, precisely because they handle customer data — apply the same standard. This requirement complements, and does not replace, the base PAW/SAW controls owned by other pillars: cross-reference the Identity pillar's Cloud Privileged Access Workstation control and the Devices pillar's Secure Admin Workstation control rather than duplicating those controls here.
For higher-assurance roles, require Secure Admin Workstations or Privileged Access Workstations for DevOps platform administrators. Cloud-hosted development environments such as Codespaces and Windows 365 provide strong isolation for everyday coding workflows, but they complement rather than replace PAW/SAW for privileged administrative tasks. A PAW enforces a trusted boot chain, hardware attestation, and strict policy baselines designed for access to Tier 0 assets — capabilities that a general-purpose cloud development environment does not provide. Organizations should maintain both tiers: PAW/SAW for platform administration and production-environment access, and cloud-hosted environments for developer productivity and code isolation.
For developer productivity scenarios that benefit from stronger isolation, standardize on cloud-hosted development environments such as Windows 365 or GitHub Codespaces. Microsoft Dev Box is now in maintenance mode and remains supported for existing use, but Windows 365 is the recommended path for new Microsoft-hosted developer desktop deployments.
Publish an approved list of IDE extensions. On Windows-managed devices, enforce approved extensions through the AllowedExtensions enterprise policy or equivalent endpoint-management controls. For broader cross-platform governance, deploy VS Code policy settings through Intune or another supported endpoint-management platform. For GitHub Codespaces, manage approved extensions through devcontainer.json configuration. Document the approved toolchain in developer onboarding standards.
Require Git commit signing with GPG or SSH keys registered in the platform. In GitHub, enforce the Require signed commits rule on protected branches or rulesets. Azure DevOps displays GPG commit signature status in the Git UI as an advisory indicator but does not natively enforce commit signing. Reinforce provenance through protected branch policies with required reviewers and build validation. Where needed, add custom pipeline validation to verify commit signatures.
Implement a pre-commit framework with hooks that run local secret detection and basic linting before code leaves the developer's machine. Treat GitHub secret scanning and push protection as server-side repository controls rather than local CLI replacements. Prohibit storing production or staging secrets in local files — use GitHub Codespaces secrets, Azure Key Vault-backed development workflows, or another approved secret-injection mechanism.
Scoping workstation assurance to the access a role can reach supports Use least privilege access, while isolating developer environments and hardening local secret handling supports Assume breach by limiting what a single compromised workstation can expose.