Azure DevOps

Access

Code Repository

Mycroft records pull request approvals, branch policies and release gates from Azure DevOps as change management evidence.

Repos and pipelines hold both halves of a change: the review that approved it and the gate that released it. Mycroft reads both, and resolves effective permissions across organization, project and repository scope for access reviews.

Find out more

How Mycroft connects to Azure DevOps

How it connects: You authorize Mycroft through Microsoft Entra OAuth against your Azure DevOps organization. The grant includes offline_access so the connection refreshes itself.
What Mycroft can access: Granted scopes are vso.code, vso.identity, vso.profile and vso.graph, which include read access to source code alongside identity and graph data. Mycroft runs a read-only pull model and does not write back.

Which controls Azure DevOps evidence maps to

Each row is a control an auditor tests and the specific artifact Mycroft collects from Azure DevOps to satisfy it. Collection runs on a schedule and every result is timestamped.

Azure DevOps compliance control mappings and the evidence Mycroft collects for each
Framework	Control	What it requires	Evidence collected from Azure DevOps
SOC 2	CC8.1	Changes are authorized, reviewed, approved and tested before release.	Pull request records with reviewers and approval timestamps, plus release pipeline approval gates showing who authorized each production deployment.
SOC 2	CC6.1	Logical access controls restrict access to information assets.	Organization, project and repository permission assignments resolved through security group membership, with Project Administrators enumerated.
SOC 2	CC6.3	Least privilege is enforced and access removed when no longer required.	Effective permission inventory reconciled against the current workforce roster, including guest and external identities.
ISO 27001	A.8.4	Access to source code is appropriately restricted.	Repository-level permission matrix with contribute, force-push and branch-policy-bypass rights identified per group.
ISO 27001	A.8.32	Changes follow documented change management procedures.	Branch policy configuration (minimum reviewers, reset votes on push, build validation, whether requesters may approve their own changes) tested continuously.
ISO 27001	A.8.25	A secure development lifecycle is followed.	Build validation policies proving automated tests and security checks ran and passed before merge was permitted.
ISO 27001	A.8.31	Development, test and production environments are separated.	Release pipeline stage configuration with environment-level approvals and checks between non-production and production.

What Mycroft collects automatically

Gathered from Azure DevOps on a schedule, dated and stored against the controls above.

Pull request history with reviewers, votes, and completion timestamps
Branch policy configuration including minimum reviewers and self-approval settings
Build validation policy status on protected branches
Pipeline and release definitions with approval gates and environment checks
Organization, project and repository permission assignments via security groups
Service connection inventory and who can use each one
Guest and external identity membership in the organization

Manual work this removes

The tasks that disappear from someone's quarter once Azure DevOps is connected.

Resolving effective permissions across organization, project and repository scope by hand
Screenshotting branch policies per repository
Assembling release approval records for production deployments
Identifying which service connections hold production credentials and who can use them

Often connected alongside:

All integrations →

Azure DevOps and Mycroft: frequently asked questions

Yes, and both are needed for a complete change management story. Repos evidences that changes were reviewed and approved; Pipelines evidences that the release into production passed its approval gates. Mycroft stores them together so a sampled deployment presents with both records attached.

The connection uses Microsoft Entra OAuth against Azure DevOps and is granted vso.code, vso.identity, vso.profile and vso.graph, plus offline_access so it can refresh. vso.code includes read access to source code. Mycroft runs a read-only pull model and does not write back.

It resolves effective permissions across organization, project, repository and pipeline scope, including membership in nested security groups. The access review shows what someone can actually do, which is usually broader than their direct assignment suggests.

Azure DevOps Services (cloud) is supported directly. On-premises Azure DevOps Server needs network reachability to the instance, so it is scoped differently.

We turn the compliance nightmare into a dream

Talk to us