14.3 Defender for Cloud DevOps Security: GitHub, Azure DevOps & GitLab

Shifting Left Without Losing the Runtime View

A hardcoded storage key in a Bicep file becomes a live credential the moment the pipeline runs. A Terraform module that omits allowBlobPublicAccess = false becomes a publicly readable container. Fixing these after deployment is expensive; catching them at pull-request time is cheap. Defender for Cloud DevOps security brings pipeline findings into the same console as runtime findings so a single team can see both ends of the same problem.

---

Connecting a DevOps Environment

Defender for Cloud supports three DevOps platforms, each with its own connector:

Onboarding requirements to remember — both halves are mandatory, and having one without the other is the most common onboarding failure:

• Contributor on the Azure subscription that will hold the connector (Defender for Cloud creates a Microsoft.Security/securityConnectors resource there). Read-only access to the resulting posture assessments can be granted more narrowly with Security Reader scoped to the resource group or connector, instead of a subscription-wide privileged role.
• Project Collection Administrator on the Azure DevOps organization, plus a Basic or Basic + Test Plans access level. Stakeholder access is not sufficient.
• Third-party application access via OAuth must be set to On for each Azure DevOps organization, or authorization fails.

Operational details that show up in scenario questions:

• Connectors auto-discover new repositories and projects as they are created, so coverage does not decay — but resources can take up to 8 hours to appear in Inventory after onboarding.
• Only one instance of a given Azure DevOps organization can be onboarded per Azure tenant.
• Defender for Cloud performs its Azure DevOps operations as the identity that authorized the connector. Repository reads, build metadata queries, and pull request annotations all appear under that account in audit logs, and if the account is removed or loses access, automated operations stop until the connector is re-authorized. Microsoft recommends a dedicated service account rather than a personal one.
• The Container Mapping extension is shared and installed automatically on connected Azure DevOps organizations so pipeline metadata such as container digests can be correlated with running resources.

---

What Gets Scanned

Onboarding gives posture visibility. To get code findings, the pipeline must run the scanners:

• Azure DevOps — install the Microsoft Security DevOps extension and add its task to the pipeline.
• GitHub — add the Microsoft Security DevOps GitHub Action to a workflow, and enable GitHub Advanced Security for its native secret, code, and dependency scanning.
• GitLab — enable the relevant GitLab scanners so results flow through the connector.

The Microsoft Security DevOps tooling is a wrapper that runs a set of open-source analysers and normalizes their output to SARIF:

Finding categories that reach Defender for Cloud:

1. Secrets in code — keys, tokens, and connection strings committed to the repository.
2. Dependency vulnerabilities — vulnerable open-source packages.
3. Code weaknesses — static analysis findings in application code.
4. Infrastructure-as-code misconfigurations — the ARM, Bicep, Terraform, and Kubernetes issues that would create insecure resources.

---

DevOps Posture Recommendations

Separately from code scanning, Defender for Cloud assesses the configuration of the DevOps platform itself. Typical recommendations:

• Repositories should have branch protection enabled on the default branch.
• Pull requests should require a minimum number of reviewers.
• Secret scanning should be enabled on the repository.
• GitHub Advanced Security should be enabled where licensed.
• Repositories should not permit force push to protected branches.
• Inactive repositories should be archived or removed, since abandoned code with live credentials is a standing risk.

These are supply-chain controls: an attacker who can push directly to main without review owns every environment that branch deploys to, regardless of how good your Azure policy set is.

---

Pull Request Annotations

Pull request annotations put the finding where the developer already is — as an inline comment on the pull request — and they annotate only the vulnerabilities introduced by the changes in that pull request, not every issue in the file. That scoping is what makes them usable rather than noise.

Azure DevOps prerequisites, in order: connect the organization, configure the Microsoft Security DevOps extension in the pipeline, and enable the Build Validation branch policy on the main branch. Only then can you select the repositories under DevOps security > Manage resources and toggle pull request annotations on. Two settings shape the output: the category — currently only Infrastructure-as-Code misconfigurations are supported — and the minimum severity to annotate, chosen from High, Medium, or Low. Both can be set at organization or project scope through the Microsoft.Security resource provider API when you need to configure them at scale.

GitHub prerequisites are the connector, the Microsoft Security DevOps GitHub Action, and a workflow trigger that includes pull_request for the branches you care about.

---

Code-to-Cloud Contextualization

The capability that distinguishes this from any standalone scanner is code-to-cloud mapping. Defender for Cloud correlates the repository and pipeline that deployed a resource with the resource itself, which enables:

• Attack paths that start in a repository — for example, "publicly exposed container → vulnerable image → the Dockerfile and repository that built it → the pull request that introduced it".
• Remediation routed to the owning team, because the finding names the repository, the file, and often the commit, rather than only the running resource.
• Prioritization by exposure, so an IaC misconfiguration that deployed to a production, internet-facing resource outranks the identical issue in a sandbox.

Know the licensing split, because it is an easy exam target. The free Foundational CSPM plan provides basic Azure DevOps posture recommendations. The advanced DevOps capabilities — pull request annotations, code-to-cloud mapping for containers and for infrastructure as code, attack path analysis, and the cloud security explorer — all require the paid Defender CSPM plan.

The workflow this enables is the point: a finding on a running Azure resource resolves to a file and a pull request, and a fix in that file prevents the misconfiguration from being re-deployed the next time the pipeline runs. Without code-to-cloud mapping, teams keep remediating the same drift because the template that causes it is never corrected.

For alerting, DevOps findings flow through the same continuous export pipeline as everything else in Defender for Cloud, so Microsoft Sentinel can raise incidents on, for example, a new secret detected in a repository that deploys to production.