Azure DevOps

The Azure DevOps integration connects your Azure DevOps organizations to Oneleet. It syncs your organizations, projects, repositories, and users as assets, and it runs monitors on your organization policies and on how your users sign in. Once it’s connected, you can add your repositories to Code Security, and Dependency Scanning runs on the repositories you add there.

Only workspace admins can connect the integration. It’s in beta, and it works with Azure DevOps Services (dev.azure.com) only, not with a self-hosted Azure DevOps Server.

Connect Azure DevOps

Before you start, find your Microsoft Entra tenant ID. This is the directory (tenant) ID or domain your Azure DevOps organization is connected to, and Azure DevOps shows it under Organization settings > Microsoft Entra.

1. On the Integrations page, click Add integration, then click the Azure DevOps card.
2. Enter your Microsoft Entra tenant ID and click Connect. Oneleet sends you to Microsoft’s sign-in page for that tenant.
3. Sign in and accept the consent screen, which Microsoft shows every time you connect.
4. When Oneleet shows “Successfully connected Azure DevOps”, click Back to integration details.

Connecting also adds Azure DevOps to your vendors.

Sign-in is limited to the Entra tenant you enter, so use the one your Azure DevOps organization is connected to, even if your own account is a guest in it. Oneleet checks only the format of the tenant ID. If you enter another tenant that you can sign in to, you still see “Successfully connected Azure DevOps”, and the problem appears only afterwards: either Azure DevOps rejects Oneleet’s requests and the connection shows “Connection failed” once it tries to sync, or the connection stays healthy but syncs nothing, with no error reported (see Fix or remove a connection). You can’t change the tenant ID on a connection after it’s created.

The connection acts as the person who signed in, and Oneleet sees what that person can see in Azure DevOps. It syncs every organization they’re a member of, and there’s no step for choosing organizations, projects, or repositories.

To add another connection, click New connection on the integration’s Settings tab. A new connection is named after the date and time it was created. To change the name, click Rename on its card.

Synced assets

Oneleet syncs four kinds of assets, automatically and many times a day:

• Organizations: each enabled organization, with two settings from Organization settings > Policies: whether IP Conditional Access policies are validated on non-interactive flows, and whether external guest access is restricted.
• Projects: each project with its description, state, and whether it’s private or public.
• Repositories: each repository with its default branch, its list of branches, and whether it’s a fork. Disabled repositories are left out because they can’t be cloned.
• Users: everyone listed under Organization settings > Users, with their license, their project group memberships, whether they’re a member or a guest, and whether they sign in through Microsoft Entra ID.

Service principals, managed identities, and groups that appear in an organization’s user list are synced as user accounts too, and so are pending invitations. A person who belongs to several organizations becomes one user, with their licenses and groups from every organization combined. That user counts as active if they’re active in any of the organizations.

Azure DevOps users appear in detected accounts and access reviews like the user accounts from your other integrations. Their MFA status always shows as unknown, because Azure DevOps doesn’t report MFA for individual users.

Monitors

A monitor runs in your workspace only when it applies to your compliance programs. The integration adds three monitors:

• Azure DevOps users sign in with Microsoft Entra ID fails for each user who doesn’t sign in through Microsoft Entra ID, which usually means a personal Microsoft account. It checks how a user signs in rather than whether they’re a guest, so a guest who signs in through Microsoft Entra ID passes. Service principals, groups, pending invitations, and disabled or deleted users aren’t evaluated.
• Azure DevOps organizations validate IP Conditional Access policies on non-interactive flows passes when that policy is turned on for the organization.
• Azure DevOps organizations restrict external guest access passes when external guest access is turned off. It checks the organization’s policy, not individual guest accounts.

The two organization monitors show as not applicable when an organization has never set the policy, or when Oneleet can’t read the organization’s policies.

A failing monitor includes the steps to fix it in Azure DevOps, and all three fixes need a Project Collection Administrator.

None of these monitors check projects, repositories, or branches. Repositories you add to Code Security are covered by the Code Security monitors instead.

Scan repositories with Code Security

Add Azure DevOps repositories to Code Security the same way as repositories from any other provider. Each one is listed under its organization and project, with its default branch already selected as the target branch. A repository with no commits has no default branch, so type the branch name instead.

The repository and branch lists come from the integration’s last sync, so a repository or branch you’ve just created doesn’t appear until the next sync. Right after you connect, the list can read “No repositories found. Check your access token permissions and try again.” until the first sync finishes.

Scans clone each repository over HTTPS using the connection’s Microsoft sign-in, which Oneleet renews automatically. Daily and manual scans work as they do for other providers, and links from a finding open the file in Azure DevOps at the right line.

These Code Security features aren’t available for Azure DevOps repositories:

• Pull request checks
• Scans triggered by a push
• Autofixes
• Cloning over SSH
• Code review evidence collection

For a feature-by-feature comparison with GitHub, GitLab, and Bitbucket, see Git provider support.

Fix or remove a connection

Each connection on the integration’s Settings tab shows its status, and the Monitors and Assets tabs show a red banner while a connection is failing. To find out what went wrong, click View status on the connection, then View failure beside the asset type that failed. The details give the reason and, under View failed requests, the responses Azure DevOps returned.

If Azure DevOps refuses Oneleet access to the projects, repositories, or users of any one organization, that kind of asset stops syncing for the whole connection, not only for that organization. Check that the person who connected still has access in every organization they belong to. If they belong to no organizations, the connection succeeds but syncs nothing, and no error is reported.

Azure DevOps connections have no Reconnect button. When a connection’s sign-in stops working, the only fix in Oneleet is to delete the connection and add a new one.

Danger

Disconnect permanently deletes the connection and every Code Security repository you added through it, including those repositories’ scans, findings, ignore rules, and dependency scan results. None of that repository data carries over to a new connection, but issues you’ve ignored for the whole workspace are kept, and any .oneleetignore or .gitleaksignore files in your repositories still apply when you add the repositories again. The confirmation dialog says only “This action cannot be undone”.

To replace a connection, open the three-dot menu on the connection card, click Disconnect, and then add a replacement with New connection. Afterwards, add the repositories to Code Security again, and Oneleet scans them from scratch.

To remove the integration along with all of its assets and data, click Remove integration under Danger zone on the Settings tab.