Microsoft Defender for Cloud DevOps Security connects to GitHub, Azure DevOps, and GitLab to centralize security across your code repositories and CI/CD pipelines. When you link these platforms, Defender for Cloud can automatically scan your code for vulnerabilities, check your pipelines for security misconfigurations, and alert your team when issues arise. The connection works through connectors that authenticate using either OAuth or service principal credentials, depending on which platform you are linking. Once connected, security policies apply to all repositories and pipelines within that connection, giving you a single view of your security posture across every project.
To connect GitHub, you authorize the Defender for Cloud connector through OAuth, which asks your GitHub account or organization for permission to access your repositories. The connector can see repositories based on your personal permissions or your organization's permissions, depending on how the authorization is set up. After connecting, you configure each repository by specifying its owner, name, which branch is the collaboration branch (usually main or master), and which branch is used for publishing. The connector then begins scanning that repository for secrets, vulnerabilities, and policy violations, reporting findings back to Defender for Cloud where you can triage and remediate them.
For Azure DevOps, you create a connector by providing a personal access token with read and write permissions to your Azure DevOps organization. The connector lists all repositories your token can access, and you choose which ones to monitor. When configuring a repository, you specify its name, the collaboration branch used for pull requests, and optionally a root folder to scan. The connector uses this information to continuously monitor the repository and its pipelines, checking both the code itself and the build definitions that run your CI/CD workflows. If the connector loses access or the token expires, scanning stops until you renew the credentials.
GitLab integration follows a similar pattern where you provide a user token that has permission to list and access projects. The connector can monitor entire groups, including projects owned by the group and any nested subgroups beneath it. When you configure a GitLab connection, you specify the group name and choose which projects within that group should be monitored. This allows Defender for Cloud to scan multiple repositories at once without configuring each one individually, which is useful when you have many projects under a single team or organization.
After connecting your platforms, you configure scanning policies that determine what Defender for Cloud looks for and how it responds. Pipeline scanning policies check your CI/CD workflows for dangerous configurations, such as exposed secrets, insecure task versions, or overly permissive permissions. Repository scanning policies find vulnerabilities in dependencies, hardcoded credentials, and other security issues in your source code. You can customize alert rules to fit your organization's tolerance for risk, choosing which findings warrant immediate notification and which can be batched into regular reports. The authentication flow you chose (OAuth for user-driven connections or service principal for automated setups) determines how Defender for Cloud maintains its access over time.
Use feature branches for development work and merge changes to collaboration branches only through pull requests, which gives reviewers a chance to catch security issues before they reach the main codebase. Store sensitive values such as connection strings, API keys, and passwords in Azure Key Vault rather than embedding them directly in your repository code, because secrets in code can be discovered by attackers who gain read access to the repository. When setting up permissions, follow the principle of least privilege by granting the connector only the access it needs to scan and monitor, and restrict who can modify publishing or deployment settings in your CI/CD pipelines. These practices work together: the connector finds issues, the scanning policies define what matters, and the authentication method keeps the connection secure over time.
Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Prepare and test your skills
Prepare and test your skills
The connection works through connectors that authenticate using either OAuth or service principal credentials, depending on which platform you are linking. OAuth is used for user-driven connections, while service principals are for automated setups.
You create a connector by providing a personal access token with read and write permissions to your Azure DevOps organization. The connector lists all repositories your token can access, and you choose which ones to monitor and configure.
Store sensitive values such as connection strings, API keys, and passwords in Azure Key Vault rather than embedding them directly in your repository code. This prevents secrets in code from being discovered by attackers who gain read access to the repository.
StudyCerts
StudyCerts