Develop a security and compliance plan
Identity and least privilege
Azure DevOps permissions flow from organisation and project groups (Project Collection Administrators, Project Administrators, Build Administrators, Contributors, Readers) down through object-level ACLs; inheritance can be disabled per object, which is a frequent question. Azure DevOps teams are not security groups - use Microsoft Entra ID groups for access. Conditional Access gates sign-in, and PATs are scoped, expiring credentials that should be avoided where a service connection or managed identity will do.
Secrets and service connections
Prefer workload identity federation on service connections over stored secrets, and managed identity for self-hosted agents. For anything else use Azure Key Vault linked variable groups - the pipeline's service connection must be authorised to read the vault. Secret variables are masked in logs but not encrypted for you; never echo them and never put them in YAML.
Pipeline and supply-chain controls
Authorise pipelines explicitly on service connections, agent pools and variable groups instead of "permit all pipelines". Protected resources plus environment checks (approvals, exclusive lock, business hours, branch control) gate deployments; by default an approver cannot approve their own run. For code and dependencies: branch policies, required reviewers, CodeQL code scanning, secret scanning with push protection, Dependabot, container and dependency scanning, and Microsoft Defender for Cloud DevOps security. Audit logs and Azure Policy supply the compliance evidence trail.
Traps
- Storing a secret in YAML, or in a variable group not backed by Key Vault.
- Handing Contributors bypass rights and calling the policy enforced.
- Reaching for a PAT when a federated service connection is the answer.
Rule of thumb
No long-lived secrets: federate identities for deployments, keep the rest in Key Vault, and put approval gates on environments rather than trusting pipeline YAML.