Quick answer
Microsoft’s new Zero Trust Workshop DevSecOps pillar contains 15 control groups and 91 tasks for applying verify explicitly, least privilege, and assume breach from source code to cloud deployment. It covers developer platforms, CI/CD, repositories, dependencies, artifacts, and infrastructure-as-code.
Use the counts as a planning inventory, not a maturity score. Every selected task needs an owner, dependency map, implementation evidence, failure test, exception process, and reassessment date.
Translate scope into control domains
| Domain | Evidence to request |
|---|---|
| Developer platform | Managed identity, admin boundaries, approved extensions, device and session policy |
| Source repositories | Branch protection, review policy, secret scanning, signed changes, access history |
| CI/CD | Isolated runners, short-lived credentials, protected environments, approval and deployment logs |
| Dependencies | Approved sources, version policy, SBOM, vulnerability and provenance checks |
| Artifacts | Signing, immutable storage, promotion gates, retention, and rollback evidence |
| Infrastructure as code | Policy checks, state protection, drift detection, scoped deployment identity |
| AI-assisted development | Code governance, tool allowlists, data protection, and ML supply-chain controls |
The Workshop also marks cross-pillar work affecting Identity, Infrastructure, and Security Operations. Do not leave these as external assumptions: assign the same task ID or dependency reference across owners so a pipeline control cannot close while its identity or monitoring dependency remains unresolved.
Apply First, Then, Next deliberately
Place foundational visibility and high-blast-radius gaps in First: inventory identities and repositories, remove shared or standing admin access, protect secrets, restrict tools, capture deployment provenance, and create a stop path. Put hardening and scale work in Then, such as broader signing coverage, policy-as-code, dependency governance, and cross-system correlation. Reserve Next for optimizations that depend on stable evidence, not for known critical exposure.
For every task, define “done” as a verifiable state. A written policy without enforcement is not implementation. A configured control without denial-path testing is not assurance. A passing test without continuous monitoring or an accountable exception owner will decay.
Add AI-specific negative tests
Test whether an AI coding tool can reveal secrets, select an unapproved dependency, alter pipeline or infrastructure files, bypass review, invoke an unapproved tool, publish an unsigned artifact, or deploy using excess privilege. Treat prompts, retrieved documentation, code comments, issue text, package metadata, and tool descriptions as potentially untrusted inputs.
Use the Assessment-to-Workshop guide to structure the broader program and agent least privilege for identities that operate development tools.
Frequently asked questions
What does the DevSecOps Workshop pillar cover?
Microsoft says it contains 15 control groups and 91 tasks spanning developer platforms, CI/CD pipelines, source repositories, dependencies, artifacts, and infrastructure-as-code.
Which tasks focus directly on AI-assisted development?
Microsoft highlights code governance, tool allowlisting, data protection, and AI and machine-learning pipeline supply-chain security.
Does completing a Workshop task prove a control is effective?
No. Require implementation evidence, an accountable owner, acceptance criteria, negative-path tests, monitoring, exception handling, and reassessment.
Official sources
Source check: August 12, 2026. Verify current Workshop content, prerequisites, task definitions, partner delivery, licensing, and terms.