How to Enable Defender for DevOps in Azure (1-6-3)

To meet the monitoring and testing elements of ECC – 2:2024 control 1-6-3, enable Microsoft Defender for DevOps in Azure by connecting each Azure DevOps organization to Microsoft Defender for Cloud, turning on the Defender for DevOps plan, and using Microsoft Security DevOps in build pipelines to identify code, dependency, secret, and infrastructure-as-code findings before release. This provides auditable security posture findings and pipeline scan results, but it must be supported by approved secure-coding standards, software library governance, penetration testing, integration testing, and production hardening evidence.

What does ECC 1-6-3 require from development teams?

ECC practice 1-6-3 requires the organization to apply cybersecurity requirements throughout software and application development. For an IT manager preparing for an NCA review, the important point is that the assessor will not accept a tool subscription alone: they will expect approved requirements, evidence that those requirements are applied to projects, and test records showing that issues are identified and handled before go-live.

Microsoft Defender for Cloud helps operationalize several parts of the practice by connecting Azure DevOps repositories and pipelines to DevOps security posture management. The Defender for DevOps plan can identify risky repository and pipeline configurations, surface development-related recommendations, and consolidate findings. Microsoft Security DevOps adds security analysis to Azure Pipelines, giving each project repeatable technical evidence for its release record.

How do you enable Microsoft Defender for DevOps in Azure?

Use a dedicated Azure subscription and resource group for the connector where practical. This makes ownership, billing, access review, and evidence collection clearer for the cybersecurity team. The administrator performing the onboarding should have sufficient rights in the Azure subscription to create the security connector and authorization in the Azure DevOps organization to approve the connection.

1. Confirm the approved scope before making the connection. List the Azure DevOps organizations, projects, repositories, and production applications that are in scope for ECC 1-6-3. Record the accountable application owner, development manager, and cybersecurity approver in the organization’s cybersecurity requirements document.
2. Open the DevOps environment onboarding page. In the Azure portal, go to Microsoft Defender for Cloud > Environment settings > Add environment > Azure DevOps.
3. Select the Azure DevOps organization. In the Azure DevOps onboarding wizard, select the applicable Azure DevOps organization. When prompted, authenticate with an account authorized to approve access to that organization. Do not connect a personal or unmanaged development organization to the corporate Defender for Cloud tenant.
4. Choose where Azure stores the connector. Select the approved Azure Subscription, Resource group, and Region. For example, use the subscription sub-security-prod, resource group rg-defender-devops-ksa, and the organization-approved Azure region. The wizard creates a Microsoft Defender for Cloud security connector resource in this location.
5. Turn on the correct plan. In the Defender plans section, set Defender for DevOps to On. Review the plan and billing confirmation, then select Connect. This is the setting that activates the Defender for DevOps integration for the selected Azure DevOps organization.
6. Confirm the connected environment is healthy. Return to Microsoft Defender for Cloud > Environment settings. Select the new Azure DevOps connector and confirm that its connection status is healthy and that the Defender for DevOps plan is enabled. Assign the cybersecurity operations team read access to the connector and findings; retain connector administration privileges only for designated cloud security administrators.
7. Install Microsoft Security DevOps for pipeline scanning. In Azure DevOps, select the organization name > Organization settings > Extensions > Browse marketplace. Search for Microsoft Security DevOps, select it, choose Get it free, select the corporate Azure DevOps organization, and complete the installation.
8. Add the scan task to each in-scope YAML pipeline. In Azure DevOps, open the project > Pipelines > select the pipeline > Edit. Add the Microsoft Security DevOps task before the build artifact is published or deployed. The task should run on pull requests and on the protected main branch.

- task: MicrosoftSecurityDevOps@1
  displayName: 'Microsoft Security DevOps scan'

- task: PublishSecurityAnalysisLogs@3
  displayName: 'Publish security analysis logs'
  inputs:
    ArtifactName: 'CodeAnalysisLogs'
    ArtifactType: 'Container'

The pipeline must be configured so that high-severity findings cannot simply be ignored by a developer. Use Azure DevOps branch policies to require a successful validation build before merging to the release branch.

1. Open the Azure DevOps project > Repos > Branches.
2. For main, select the More options menu > Branch policies.
3. Under Build validation, select +, choose the security-enabled pipeline, set Trigger to Automatic, and enable Required.
4. Under Require a minimum number of reviewers, require at least two reviewers for production applications, including an application owner or delegated security reviewer for high-risk changes.

Also reduce pipeline credential exposure through Azure DevOps organization settings. Go to Organization settings > Pipelines > Settings, then turn on Limit job authorization scope to current project for non-release pipelines, Limit job authorization scope to current project for release pipelines, and Protect access to repositories in YAML pipelines.

How can you verify that Defender for DevOps is working?

Verification should prove both that the connector is active and that projects are actually producing security results. In the Azure portal, go to Microsoft Defender for Cloud > DevOps security. Confirm that the connected Azure DevOps organization is displayed and that repositories or projects appear in the inventory. Review Recommendations and filter for the Azure DevOps environment to confirm that posture findings are being generated.

Then verify the pipeline path in Azure DevOps. Go to the project > Pipelines > select a completed run > Job. Confirm that the Microsoft Security DevOps scan step completed and that the Publish security analysis logs step published output. Review the run’s logs and artifacts for findings, including secrets, vulnerable dependencies, insecure infrastructure-as-code settings, or code-analysis results.

For an additional Azure-side check, open Azure portal > Resource Graph Explorer and run the following query. It should return the security connector created for the DevOps organization.

securityresources
| where type =~ 'microsoft.security/securityconnectors'
| project name, resourceGroup, subscriptionId, properties

What evidence should be captured for an NCA assessor?

Capture evidence at the time of onboarding, at least quarterly during control operation, and for each significant application release. Screenshots should include the portal breadcrumb, tenant or organization name, date, and visible status; a cropped image without context is difficult to defend during an ECC review.

Maintain a project-to-evidence index that maps each production application to its repository, pipeline, latest scan date, latest penetration test date, integration test report, and go-live approval. This index is particularly useful when the assessor samples a specific application rather than reviewing the platform generally.

Where does Defender for DevOps fall short of ECC 1-6-3?

Defender for DevOps is a strong technical control, but it does not independently satisfy all five ECC 1-6-3 objectives. It does not write or approve the organization’s secure coding standard, prove that every third-party library is licensed, perform a full business-context penetration test, validate every API integration, or approve production hardening and patching.

Fill these gaps with governance and complementary controls: maintain an approved secure coding standard for 1-6-3-1; use an approved software catalog and software composition analysis process for 1-6-3-2; perform documented SAST, DAST, penetration testing, and architecture reviews for 1-6-3-3; retain system integration testing and API test reports for 1-6-3-4; and require secure configuration, patch verification, and go-live checklists for 1-6-3-5. Treat the Defender for DevOps integration as the central evidence source for DevOps posture and pipeline findings, not as a substitute for those required processes.

Next, connect one production Azure DevOps organization, run the security-enabled pipeline on a representative application, and add the resulting evidence to your ECC 1-6-3 review pack.