Azure DevOps
Overview
The Azure DevOps connector links your Azure DevOps organization to Nullify so that source-control activity drives security scanning, pull request reviews, and two-way ticket status sync — without developers leaving their existing workflow.
For a new workspace, Nullify sends a setup invitation. Open that link and finish Microsoft and Azure DevOps checks before onboarding. The Request workspace button on No workspace yet does not claim a prepared workspace. See Set up a new workspace.
An administrator clicks Connect Azure DevOps, completes Microsoft administrator consent and sign-in, then selects organizations. Nullify adds its service principal, grants scoped permissions across their visible projects, checks access, creates service hooks, and syncs repositories. Select repositories in Onboarding and choose Finish setup to request the first scan; some workspaces require Nullify to start it. There's no app registration to create and no client secret to copy into Nullify.
Setup requests delegated Azure DevOps access (user_impersonation) plus openid profile email. The delegated token lets Nullify perform the setup with the signed-in administrator's authority. Ongoing access uses Nullify's service principal and the permissions granted in Azure DevOps. Entra consent alone does not grant that principal access to your organization. The Install guide lists the permissions and revocation steps.
What you get
Pull request reviews
When a pull request is created or updated in a connected repository, Nullify reviews the changed code and posts its findings back as a PR review. Replies to Nullify's PR comments are also handled: when a developer comments on a Nullify review thread, the connector picks up the reply and continues the conversation in-thread.
Pull request gating and review behaviour use the dashboard's available policy controls or the admin API (older dashboards use Configure → Pull Requests), including whether the "Nullify" check can fail the build on net-new findings at or above your chosen priority threshold.
Autofix pull requests
Nullify opens autofix pull requests on Azure DevOps: it creates a branch in the connected repository, commits the fix, and opens a pull request for your team to review. Re-running a fix on a branch that already exists repoints that branch, which is a non-fast-forward update — the reason the connector holds the Force push permission listed in the Install guide.
Push scanning
Every push to a connected repository is delivered to Nullify. The connector emits a scan event for each updated branch (tag pushes and branch deletions are ignored), and pushes to the repository's default branch additionally trigger the default-branch pipeline so your baseline security posture stays current.
Work-item (ticketing) status sync
When Nullify files a finding as an Azure DevOps work item, work-item updated events flow back to Nullify. A state change on a tracked work item (for example moving it to Resolved, Closed, or Done) is synced to the matching Nullify finding ticket, keeping the finding's status aligned with what your team does in Azure Boards. Nullify maps Azure's out-of-the-box state vocabulary by default and honours a per-tenant status map for teams running a custom Azure Boards process.
Events the connector subscribes to
Nullify creates Azure DevOps service-hook subscriptions for the following events on each connected organization, automatically as part of connecting:
Code pushed
git.push
Push scanning (all branches + default branch)
Pull request created
git.pullrequest.created
PR reviews
Pull request updated
git.pullrequest.updated, filtered to source-branch pushes and status changes (two subscriptions)
PR reviews; reviewer votes are not delivered
Pull request commented
ms.vss-code.git-pullrequest-comment-event
PR review replies
Pull request merged
git.pullrequest.merged
Keeping merge/close state in sync
Work item updated
workitem.updated
Ticket status sync — subscribed only when you tick File findings as Azure Boards work items
Webhook deliveries are authenticated: each subscription carries an HTTP Basic credential (username nullify plus a per-install shared secret), and Nullify rejects deliveries that don't match.
Capability differences vs GitHub
No blame API. Nullify falls back to the file's most recent contributor wherever it would otherwise use line-level blame.
No force-push detection. Nullify does not react to a force-push on one of your branches the way it does on GitHub; each push is handled independently. (This is about incoming force-pushes — Nullify does force-push its own autofix branch when it repoints one.)
Iteration-tracked PR comments. Azure DevOps threads review comments to a pull request iteration rather than a commit SHA.
See the Install guide for more detail.
Tenants
Nullify prepares the workspace before sign-in can open it. No workspace yet does not create one, and Request workspace does not replace the setup invitation. Microsoft sign-in and the Azure DevOps connection are separate after the workspace exists. See Microsoft sign-in.
Setup
The full walkthrough — administrator consent, sign-in, setup checks, permissions and troubleshooting — lives in the Azure DevOps Install guide.
Last updated