This chapter covers Microsoft Defender for DevOps, a cloud-native application security tool that integrates security into Azure DevOps and GitHub pipelines. It is a critical topic for the AZ-500 exam because it addresses the growing need to secure the software supply chain—an area that now appears in roughly 5-8% of exam questions. You will learn how Defender for DevOps scans code, containers, and infrastructure as code (IaC) for vulnerabilities, secrets, and misconfigurations, and how it provides actionable remediation guidance. By the end, you will understand how to enable and configure it, interpret its findings, and integrate it with other Defender for Cloud features.
Jump to a section
Imagine a busy international airport. Passengers (code commits) arrive at check-in (source control). Before entering the secure area, they go through security screening (pre-commit scanning). The security officer checks IDs and scans bags for prohibited items—this is like scanning for secrets and vulnerabilities in code before it merges. Once cleared, passengers proceed to the boarding gate (CI/CD pipeline). At the gate, they go through additional screening (build-time scanning) for liquids, electronics, etc.—equivalent to scanning dependencies and container images for known vulnerabilities. Finally, as they board the plane (deployment), a last check ensures no one swapped bags (post-deployment monitoring). The airport's central command center (Microsoft Defender for Cloud) monitors all checkpoints, alerts on suspicious activity (e.g., a passenger trying to bypass security), and provides a unified dashboard. If a threat is detected—like a passenger with a fake ID (a compromised credential)—the command center can halt the boarding process (block the pipeline) and initiate an investigation. This layered, integrated security model mirrors how Defender for DevOps protects the entire software supply chain.
What is Microsoft Defender for DevOps?
Microsoft Defender for DevOps is a security solution within Microsoft Defender for Cloud that provides end-to-end protection for DevOps environments. It supports Azure DevOps (ADO) and GitHub repositories, scanning code repositories, build pipelines, and container registries for security issues. The service helps organizations adopt a 'shift-left' security approach by identifying vulnerabilities early in the development lifecycle. It is particularly focused on: - Infrastructure as Code (IaC) misconfigurations – Using tools like Microsoft Security Code Analysis (MSCA) and Checkov to detect insecure Terraform, ARM, Bicep, and CloudFormation templates. - Secrets exposure – Detecting hardcoded secrets (API keys, passwords, certificates) in source code using Credential Scanner. - Vulnerable dependencies – Scanning for known vulnerabilities in open-source packages via GitHub Advisory Database and Trivy. - Container vulnerabilities – Scanning container images in Azure Container Registry (ACR) for CVEs. - Code quality and security – Using CodeQL to perform semantic code analysis for security bugs.
How It Works Internally
Defender for DevOps operates through a set of connectors and scanners that are integrated into the DevOps workflow. The process can be broken down into the following phases:
1. Connector Setup – An administrator connects Defender for Cloud to an Azure DevOps organization or GitHub account. This requires granting read permissions to repositories and pipelines. The connector establishes a webhook or polling mechanism to receive events (e.g., push, pull request, pipeline run).
2. Scanning Trigger – Scans can be triggered automatically on events (e.g., every push to a branch, every pull request) or on a schedule (e.g., daily). The scanner runs as part of the CI/CD pipeline or as a GitHub Action. For Azure DevOps, a build task is added to the pipeline YAML. For GitHub, a workflow YAML file is created.
3. Scanning Engines – Multiple scanning engines are invoked: - Credential Scanner – Pattern-matching and entropy detection for secrets. - CodeQL – Compiles code into a queryable database and runs security queries (e.g., SQL injection, XSS). - IaC scanner – Uses Checkov (open-source) to evaluate Terraform, ARM, etc. against hundreds of policies (e.g., Azure CIS benchmarks). - Dependency scanning – For npm, NuGet, Maven, PyPI, etc., comparing lock files against known vulnerability databases. - Container scanning – For Docker images in ACR, using Trivy or similar to check for CVEs.
4. Results Ingestion – Scan results are sent to Defender for Cloud via API. Each finding includes severity (Critical, High, Medium, Low), file path, line number, and remediation guidance. Findings are stored in the Defender for Cloud workspace and can be viewed in the 'DevOps Security' blade.
5. Remediation and Enforcement – Security teams can set policies to block PRs or builds if certain severity thresholds are exceeded. For example, a policy can block a build if any critical vulnerability is found. Developers receive inline annotations in pull requests (e.g., GitHub checks) showing the issues.
Key Components and Defaults
Connectors – Each Azure DevOps organization or GitHub account requires a connector. Connectors are created in Defender for Cloud under 'Environment settings' > 'DevOps security'. You must have at least 'Security Admin' role.
Scanning triggers – By default, scans run on pull request and push events. You can also configure scheduled scans (e.g., daily).
Severity thresholds – Default policy blocks PRs on critical and high severity findings. You can customize per repository.
Retention – Findings are retained for 90 days. After that, they are automatically deleted.
Pricing – Defender for DevOps is included in Defender for Cloud's CSPM (Cloud Security Posture Management) plan. No additional per-scan cost, but Azure DevOps or GitHub usage may incur charges.
Configuration and Verification Commands
To enable Defender for DevOps for an Azure DevOps organization:
In Azure Portal, navigate to Microsoft Defender for Cloud > Environment settings > DevOps security.
Click 'Add connector' and select Azure DevOps.
Authorize the connector by signing in with an Azure DevOps account that has 'Project Collection Administrator' permissions.
Select the organization and optionally specific projects/repositories.
Configure scanning settings (e.g., enable automatic PR scanning).
To verify the connector is working:
In Defender for Cloud, go to 'DevOps security' > 'Connectors'. The status should show 'Connected'.
Trigger a push to a repository. After a few minutes, check the 'DevOps security' blade for findings.
Using Azure CLI to list connectors:
az security devops connector list --resource-group <rg-name>For GitHub, the process is similar but requires installing the Defender for DevOps GitHub App.
Interaction with Related Technologies
Defender for DevOps integrates tightly with: - Microsoft Defender for Cloud – All findings appear in the unified security alerts and recommendations. You can correlate DevOps findings with other cloud security issues. - Azure Policy – You can create custom policies to enforce scanning on all repositories. - Microsoft Sentinel – DevOps security alerts can be sent to Sentinel for SIEM correlation. - GitHub Advanced Security – Overlaps with GitHub's own code scanning and secret scanning. Defender for DevOps provides a single pane of glass across multiple platforms.
Common Misconfigurations
Insufficient permissions – The connector service principal must have read access to repositories. If not, scans fail silently.
Ignoring scheduled scans – Relying only on PR scans misses issues in merged code. Always enable daily scans.
Not configuring blocking policies – Without policies, developers may ignore findings. Set build breakers for critical/high.
Step-by-Step: Enabling Defender for DevOps on a GitHub Repository
In Defender for Cloud, add a GitHub connector (requires GitHub admin approval).
Install the 'Microsoft Defender for DevOps' GitHub App in your organization.
Select repositories to scan.
In the repository, a workflow file .github/workflows/defender-for-devops.yml is automatically created (or you can add it manually).
Push a change to trigger the workflow. The workflow runs msdo (Microsoft Security DevOps) action, which invokes multiple scanners.
View results in the GitHub 'Security' tab or in Defender for Cloud.
Troubleshooting
No findings – Check that the scanner is actually running. Look at workflow logs. Ensure the repository has code (e.g., not empty).
Connector status 'Disconnected' – Reauthorize the connector. Permissions may have expired.
Scans taking too long – For large repositories, limit scanning to specific paths or use incremental scanning.
Best Practices
Enable on all repositories – Use Azure Policy to enforce connector creation.
Integrate with pull request checks – Require passing security scans before merging.
Review findings regularly – Assign ownership to developers.
Combine with DDoS protection – Not directly related, but overall security posture.
Defender for DevOps is a powerful tool for shifting security left. It reduces the cost and effort of fixing vulnerabilities by catching them early. On the AZ-500 exam, expect questions about connector setup, scanning triggers, and interpreting findings.
Create a Defender for Cloud connector
Navigate to Microsoft Defender for Cloud in the Azure portal. Under 'Environment settings', select 'DevOps security'. Click 'Add connector' and choose either Azure DevOps or GitHub. For Azure DevOps, you must sign in with an account that has 'Project Collection Administrator' permissions. The connector establishes a trust relationship, allowing Defender for Cloud to receive events and scan results. This step is prerequisite for any scanning. Without a connector, no data flows into Defender for Cloud.
Authorize and configure connector permissions
After selecting the connector type, you are redirected to authorize the connection. For Azure DevOps, you grant consent for the 'Defender for Cloud' app to access your organization. For GitHub, you install the 'Microsoft Defender for DevOps' GitHub App and specify repository access (all or selected). The app is granted read-only permissions to code, pull requests, and workflows. This step ensures the scanner can read your code and pipeline definitions. Insufficient permissions will cause scan failures.
Select repositories and enable scanning
Once the connector is created, you can select which projects (Azure DevOps) or repositories (GitHub) to scan. By default, all current and future repositories are included. You can also configure scanning triggers: on push, on pull request, or on a schedule. For Azure DevOps, you need to add a build task to your pipeline YAML (e.g., 'MicrosoftSecurityDevOps@1'). For GitHub, a workflow file is automatically added. This step activates the actual scanning.
Run scans and view results
After configuration, scans run automatically based on triggers. For example, a pull request triggers a scan that runs as a GitHub Action. The scan outputs findings as annotations on the PR. In Defender for Cloud, results appear under 'DevOps security' > 'Findings'. Each finding includes severity, file path, and remediation guidance. You can also see aggregated metrics like 'Critical findings per repository'. This step is where you see the value of the tool.
Set policies to block or alert
To enforce security, you can configure policies that block pull requests or builds if certain severity thresholds are exceeded. In Defender for Cloud, go to 'DevOps security' > 'Policies'. Create a policy that, for example, blocks a PR if any critical vulnerability is found. This ensures that insecure code never reaches production. Policies can be scoped to specific repositories or applied globally. This is the final step to operationalize security.
Enterprise Scenario 1: Financial Services Company Securing CI/CD
A large bank uses Azure DevOps to manage hundreds of microservices. They were struggling with secret leakage—developers accidentally committing API keys to public repositories. They deployed Defender for DevOps across all projects. The credential scanner immediately detected over 200 exposed secrets, including production database passwords. The security team set a policy to block any build with a hardcoded secret. Within a week, the number of new secrets dropped to near zero. The tool also scans IaC templates for misconfigurations like open security groups. One developer's Terraform template had an unrestricted SSH rule; Defender flagged it before deployment. The bank estimates they prevented at least three potential breaches in the first month.
Scenario 2: E-commerce Company Using GitHub
An online retailer with a large GitHub Enterprise footprint wanted to consolidate security findings. They had separate tools for code scanning, secret scanning, and dependency scanning. Defender for DevOps unified all scans into a single dashboard. They configured scheduled scans to run nightly on all repositories. The container scanning component found a critical CVE in a base image used by 50 services. The team was able to rebuild all images within hours. They also used the pull request annotations to give developers immediate feedback. The security team now spends less time triaging and more time on strategic initiatives.
Scenario 3: SaaS Startup with Limited Security Team
A 50-person startup had no dedicated security engineer. They enabled Defender for DevOps on their GitHub repositories with default settings. The tool automatically blocked any PR that introduced a critical vulnerability. Developers initially complained about delays, but quickly learned to fix issues before committing. The startup avoided a major incident when a dependency scan revealed a known exploit in a logging library they were about to deploy. The automated blocking policy prevented the vulnerable code from reaching production. The startup's CTO noted that Defender for DevOps 'paid for itself' in the first month.
Common Pitfalls
Overblocking – Setting policies too strict (e.g., blocking on medium severity) can slow development. Tune thresholds based on risk appetite.
Ignoring false positives – Some scanners may flag benign code (e.g., test secrets). Use suppression rules to reduce noise.
Not training developers – Without understanding, developers may bypass scans. Provide training on reading findings.
Performance Considerations
Scans can take 5-30 minutes depending on repository size. For monorepos, consider path filters to scan only changed files.
Scheduled scans should be staggered to avoid overwhelming the CI/CD system.
Connector limits: Up to 100 connectors per Azure subscription. Each connector can handle thousands of repositories.
Defender for DevOps is a production-ready tool that scales from startups to large enterprises. It integrates seamlessly with existing workflows and provides immediate value.
What AZ-500 Tests on Defender for DevOps
The AZ-500 exam objective '4.1 Implement security for DevOps' covers Defender for DevOps. You should know:
How to enable and configure connectors for Azure DevOps and GitHub.
The types of scans: secrets, IaC misconfigurations, dependency vulnerabilities, container vulnerabilities, and code quality (CodeQL).
How to interpret findings (severity, file path, remediation).
How to set policies to block builds or PRs.
Integration with Defender for Cloud and Azure Policy.
Common Wrong Answers and Why
'Defender for DevOps only scans containers.' – Wrong. It scans code, IaC, secrets, dependencies, and containers. Candidates confuse it with Azure Container Registry scanning.
'You need to install an agent on each build agent.' – Wrong. Scans run as tasks in the pipeline or GitHub Actions, no agents required.
'Defender for DevOps replaces GitHub Advanced Security.' – Wrong. It complements it, providing a unified view across multiple platforms.
'Findings are only visible in the DevOps tool, not in Defender for Cloud.' – Wrong. All findings appear in Defender for Cloud's dashboard.
Specific Numbers and Terms
Connector types: Azure DevOps and GitHub (not GitLab, Bitbucket as of exam date).
Severity levels: Critical, High, Medium, Low.
Default policy: Block on Critical and High by default.
Retention: 90 days.
Scanner names: Credential Scanner, CodeQL, Checkov, Trivy.
Required role: Security Admin to create connectors.
Edge Cases and Exceptions
Private repositories – Scans work on private repos, but you must grant the connector access.
Multi-organization – You need separate connectors for each Azure DevOps organization or GitHub account.
Scheduled scans – If no code changes, scheduled scans still run (daily by default).
Blocking policies – They only block if the scan runs as part of the PR. If a developer bypasses the scan, the policy won't block.
How to Eliminate Wrong Answers
If an answer says 'only scans at build time', it's wrong because it also scans on push and PR.
If an answer says 'requires on-premises agent', it's wrong because it's cloud-native.
If an answer says 'findings are only in the DevOps tool', it's wrong because they appear in Defender for Cloud.
If an answer says 'supports GitLab', it's wrong (as of exam objectives).
Focus on understanding the connector setup and the types of scans. The exam will test your ability to identify the correct configuration steps and the scope of the tool.
Defender for DevOps supports Azure DevOps and GitHub connectors only (not GitLab or Bitbucket as of exam date).
Scans include: secrets, IaC misconfigurations, dependency vulnerabilities, container vulnerabilities, and code quality (CodeQL).
Connectors require Security Admin role and read permissions to repositories.
Findings are retained for 90 days in Defender for Cloud.
Default policy blocks PRs on Critical and High severity findings.
Scheduled scans run daily by default, in addition to event-driven scans.
Defender for DevOps is included in Defender for Cloud's CSPM plan (no extra cost per scan).
These come up on the exam all the time. Here's how to tell them apart.
Defender for DevOps
Supports both Azure DevOps and GitHub.
Integrates with Microsoft Defender for Cloud for centralized alerting.
Includes IaC scanning (Checkov) and container scanning (Trivy).
Can block PRs or builds via Azure Policy integration.
Provides a unified dashboard across multiple DevOps platforms.
GitHub Advanced Security
Only works with GitHub repositories.
Standalone product, no integration with Azure Defender for Cloud (though can send alerts).
Focuses on code scanning (CodeQL), secret scanning, and dependency review.
Blocking is done via GitHub's branch protection rules, not Azure Policy.
Only covers GitHub ecosystem.
Mistake
Defender for DevOps only works with Azure DevOps.
Correct
It supports both Azure DevOps and GitHub. GitLab and Bitbucket are not supported as of the current exam objectives.
Mistake
Defender for DevOps requires an agent to be installed on build servers.
Correct
No agent installation is needed. Scans run as tasks in Azure Pipelines or as GitHub Actions, using Microsoft-hosted or self-hosted agents but without additional software.
Mistake
Defender for DevOps only scans for secrets.
Correct
It scans for secrets, IaC misconfigurations, vulnerable dependencies, container vulnerabilities, and code quality issues (CodeQL).
Mistake
You must manually configure each repository's scan settings individually.
Correct
You can configure scanning at the connector level for all repositories, or selectively. Default settings apply to all repos unless overridden.
Mistake
Defender for DevOps findings are only visible in the DevOps tool (e.g., GitHub Security tab).
Correct
Findings are also visible in Microsoft Defender for Cloud under 'DevOps security', providing a centralized view.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In Azure Portal, go to Microsoft Defender for Cloud > Environment settings > DevOps security. Click 'Add connector', select Azure DevOps, and sign in with an account that has 'Project Collection Administrator' permissions. Authorize the connection, then select the organization and repositories to scan. Add the 'MicrosoftSecurityDevOps@1' task to your pipeline YAML to enable scanning.
It uses Credential Scanner for secrets, CodeQL for code quality, Checkov for IaC misconfigurations, and Trivy for container vulnerabilities. Dependency scanning uses GitHub Advisory Database and other sources.
Yes. You can configure policies in Defender for Cloud that block PRs based on severity thresholds. For example, a policy can block a PR if any critical vulnerability is found. This is enforced via status checks in the DevOps tool.
Yes, it can scan container images stored in ACR for vulnerabilities. This is part of the container scanning capability, using Trivy or similar scanners.
You need at least 'Security Admin' role in Azure. For Azure DevOps, you also need 'Project Collection Administrator' permissions in the Azure DevOps organization. For GitHub, you need admin access to the GitHub organization to install the GitHub App.
Findings are retained for 90 days. After that, they are automatically deleted. You can export findings to Log Analytics for long-term retention.
Defender for DevOps is included in the Defender for Cloud CSPM (Cloud Security Posture Management) plan. There is no additional per-scan charge, but you may incur costs for Azure DevOps or GitHub usage.
You've just covered Microsoft Defender for DevOps — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?