Azure DevOps is where your source code, build definitions, service connections, and deployment credentials all live. That makes it one of the highest-value targets in your engineering estate — and one of the hardest surfaces to govern, because its security posture is spread across organization settings, project settings, pipeline YAML, and per-tool configuration.
This guide collects the practices that actually move the needle for AppSec and platform teams, and looks honestly at the operational gap most checklists ignore: keeping these practices true over time, across hundreds of pipelines.
Start at the organization boundary
Everything inherits from the organization. Before touching pipelines, get the boundary right.
- Enforce Microsoft Entra ID authentication and conditional access; retire personal access tokens where service principals or managed identities work.
- Audit who holds Project Collection Administrator — the list is almost always longer than anyone expects.
- Restrict new project creation and service connection creation to a controlled group.
- Review OAuth app access policies and disable what nobody can name a reason for.
Treat service connections as production credentials
Service connections are deployment credentials with a friendly UI. A pipeline that can use a service connection can act as it. Scope each connection to the narrowest set of pipelines, prefer workload identity federation over stored secrets, and review grants regularly — especially the 'grant access to all pipelines' checkbox, which quietly turns one connection into an organization-wide credential.
Make security scanning a property of the pipeline, not a request to the team
The most common failure mode in Azure DevOps security is not a missing tool. It is a scanner that was added to some pipelines, by some teams, at some point — and nobody can say today which builds are actually covered.
Coverage has to be observable and enforceable: which pipelines are eligible for scanning, which are enrolled, which drifted, and which are explicitly excluded with a recorded reason.
Decide centrally what a finding does to a build
A severity threshold configured pipeline-by-pipeline is not a policy — it is a suggestion. Policy needs one authoritative home: evaluated in a backend, applied consistently, and changed through an audited path rather than a YAML edit.
Where Kangl fits
Kangl is a security control plane for Azure DevOps. It connects your organizations, discovers projects, repositories, and eligible build pipelines, manages providers such as Snyk through Kangl Pipeline Security Runtime, keeps pipeline security state synchronized, and makes policy decisions backend-authoritative — with a durable audit trail behind every operation.
The practices above stop being a quarterly cleanup project and become the standing state of the estate.
