Managing Security Center at scale using ARM templates and Azure Policy
*** Update: This blogpost has been updated with a new ARM template and new Azure Policy definitions which covers the new Security Center bundle pricings. The new ARM template can be found here, the new Azure Policy definitions can be found here *** Recently we have been receiving several customer questions on how to manage Security Center at scale in a continuous integration (CI) and continuous delivery (CD) scenario, better known as CI/CD. How do you make sure that when a new subscription is instantiated, Security Center is configured correctly and is enabled to monitor new and existing resources? How do you manage hundreds of subscriptions within your organizattion? How do you enforce your security policies? This blogpost covers two scenarios: Configure Security Center using an ARM template to support a CI/CD scenario and management at scale Enforce a Security Center configuration within your organization, using Azure Policy Since both ARM templates and Azure Policy talk to the Resource Manager API in Azure, by making a JSON formatted request, you can re-use the deployment section of an ARM template to author an Azure Policy definition. If you are new to ARM templates and are looking for guidance on authoring, go here. In case you want to leverage PowerShell for configuring ASC, go here. The Security Center ARM Template Every ARM template consists of these 7 elements (not all of them have to be used): It’s the “resources” element that we are interested in since the ARM template reference for Security Center hasn’t been documented yet. We are in the process of publishing which makes it easier to find which types and values are allowed and will also provide IntelliSense. I will update this post when that becomes available. In this blogpost I will cover the two most asked questions: How can I make sure that Security Center is configured for the Standard pricing tier, which unlocks all the Security Center features How can I enable auto provisioning, which enables automatic installation of the Microsoft Management Agent (MMA) VM extension for new resources. Please refer to the pricing tier documentation for the difference between the Free and Standard tier. Set the ASC pricing tier in an ARM template The new pricing tier API is fast and efficient to use. We are using the Microsoft.Security/pricings type to set our pricing tier. How does that look in a template? The ARM template can be found here. If you want to deploy this template, please make sure you target the subscription instead of a resource group. This is a common made mistake, since ASC lives at the subscription level, not at the resource group level. A deployment would look like this (using PowerShell): New-AzDeployment -Name myAscDeploy -Location <yourLocation> -TemplateFile ‘<yourTemplateFileAndPathHere>' -Verbose Since you have probably noticed the usage of a parameter, so you can flip it from “Free” to “Standard” or the other way around, you will be prompted for this value. Please note that we are only allowing the two values specified and it is case sensitive. You can verify the deployment in the activity log: Leveraging the ARM template to create an Azure Policy Now that you have a working ARM template, you can use it to create a deployIfNotExists type of Azure policy which allows you to remediate if the policy definition is non-compliant. If you are just starting with Azure Policy, I would recommend to explore our documentation for guidance on different policy definitions. Leveraging the ARM template we just created, you can construct a deployIfNotExists Azure Policy. You first need to create the section that allows you to find the pricingTier field and value (Standard). For this to work, you need to target your Policy at the right scope (subscriptions or higher), then you define the “effect” (deployIfNotExists) and you set the type to Microsoft.Security/pricings, where the field and value lives which we are looking for. If the existenceCondition returns false and you want to remediate it, you need to define a deployment section under the resources section, where you define your target type and properties. You can find the Azure Policy shown above here. Having your ARM Policy defined, you can now create and assign your new Azure Policy. Please note that you need the appropriate permissions to create a managed identity. This ensures that the policy has the appropriate permissions to change the Security Center configuration at the subscription level. It takes around 30 minutes for the policy to take effect as mentioned in the confirmation. Your policy will remain in this state for a while: Then after around 30 minutes, you will notice a non-compliant assignment, as shown below. If you click on the assignment, you can explore which resource is non-compliant. You can click on Create Remediation Task to remediate it. Automatically create a remediation task In case you want to use automation, you can leverage the Policy Insights API to create a remediation task. One of the options you have is to invoke the API using PowerShell. The script below shows an example how to accomplish that. Please note that besides the subscriptionId, you need to pass a remediationName and policyID: You can find the script to create a remediation task here. If you have succesfully executed the script, you should see something similar in your activity log: Your ASC pricing tier should be changed to Standard and after a policy refresh cycle, your compliance state should be updated to compliant. Configure Security Center auto provisioning using a custom workspace The following ARM template enables auto provisioning so that the Microsoft Management Agent VM extension will be deployed automatically to new created virtual machines. You will also configure a custom Log Analytics workspace instead of the default Security Center one. The ARM template for enabling auto provisioning can be found here. Please note that you need to pass specific parameters values for configuring the Log Analytics workspace like workspace name, the resource group of the workspace and the Azure subscriptionID of where the workspace is created. Deployment of the ARM template is straightforward as you have seen before while deploying the pricing tier template and should look like this:Using Azure Security Center API for Workflow Automation
Workflow Automation is a new Azure Security Center feature (preview) that can trigger Logic Apps on security alerts and recommendations. In this blog post, we will demonstrate how we can use API to build and answer more unique triggering scenarios.Automate Azure Security Center actions with Playbooks and ServiceNow
Logic Apps provides an excellent way to automate Azure Security Center actions like responding to alerts or recommendations. In this blogpost, we will create a Logic Apps playbook that will create a record in ServiceNow. This prevents you from manually creating a ticket in ServiceNow and populate the fields that the playbook can automatically fill in for you. Add a Security Center playbook to integrate ServiceNow Logic Apps has out of the box integrations with third party vendors like ServiceNow, this makes it very easy to integrate Azure Security Center. We can leverage ServiceNow Record actions like Create, Delete, Get, Update, etc. Navigate to the Azure Security Center portal and under Automation and Orchestration, select Playbooks Click on Add Playbook Provide a name for your new playbook like “ASC-Alert-To-ServiceNow” and fill in the resource group and location fields. The Log Analytics integration offers capabilities like using search to query the status and history of your playbooks. Click on Create In the Logic Apps Designer select the Blank Logic App template Search for Azure Security Center and select When a response to an Azure Security Center alert is triggered as the trigger Note: adding the Azure Security Center trigger makes your playbook visible in the Azure Security Center alerts blade 6. Click on + New Step and search for ServiceNow 7. Select Create Record as the action 8. To continue, you need to create a ServiceNow connection Note: if you don’t have a ServiceNow environment you can sign up here for a developer instance 9. Fill in the required fields to create the connection 10. Now you need to pass values from the Security Center alert trigger so that we can automatically populate the ServiceNow record. For creating a new incident record, we need to populate at least the Caller and Short description field as shown in the ServiceNow Incident New Record screen: 11. Back to your Logic Apps Playbook ServiceNow action, select Incident as your Record Type: 12. Fill in the values for at least Caller and Short Description, but you can add any alert fields which are of interest: 13. Save your Logic Apps playbook, your playbook should look like this: 14. Switch to Security Alerts in Azure Security Center (under Threat Protection). 15. Click on the security alert, you should see something similar like this: 16. Click on the alert one more time, which reveals the alert details, and the View playbooks button becomes available: 17. Click on the View playbooks This shows which playbooks are available in Azure Security Center 18. Click on the Run button to start the playbook you have created. This will pass the alert information and context. Note: The Run history tab shows previously invoked playbooks and status 19. After the playbook has ran successfully, you can see the record created in ServiceNow: How to automate this end to end? Look at this blogpostAutomation to block compromised identity detected by Microsoft Defender for Resource Manager
If an account is compromised you would disable the account temporarily, revoke all the associated authentication token, and reset the password. To automate this process, you can use the Azure Logic App we have developed to disable the account, revoke all the active tokens and notify the account’s manager if it exists or simply to a designated email address.Microsoft Defender for Cloud Innovations at Ignite 2025
In today’s AI-powered world, the boundaries of security are shifting fast. From code to runtime, organizations are moving faster than ever – building with AI across clouds, accelerating innovation, and expanding the landscape defenders must protect. Security teams are balancing fragmented tools, growing complexity and a new generation of intelligent, agentic systems that learn, adapt and act across the digital estate. The challenge isn’t understanding the change – it’s staying ahead of it. At Ignite 2025, we’re unveiling four major advancements in Microsoft Defender for Cloud that redefine how security keeps pace with cloud-scale innovation and AI autonomy. Together, they advance a simple idea – that security should move as fast as the systems it protects, adapting in real time to new patterns of risk. Defender for Cloud + GitHub Advanced Security integration delivers AI-driven, automated remediation We start where every application does: in the code – and with a major step forward in how security and development teams work together. The pace of development has scaled dramatically. Organizations now build more than 500 new apps 1 on average each year – and as code volume grows, the gap between development and security widens. Working in separate tools with no shared context, developers can’t see which threats security teams prioritize, and security teams can’t easily trace issues back to their source in code. To help organizations address this challenge, Microsoft Defender for Cloud now natively integrates with GitHub Advanced Security (in public preview) – the first native link between runtime intelligence and developer workflows, delivering continuous protection from code to runtime. This bidirectional integration brings Defender for Cloud’s runtime insights directly into GitHub, so vulnerabilities can be surfaced, prioritized, and remediated with AI assistance – all within the developer environment. When Defender for Cloud detects a critical vulnerability in a running workload, developers see exactly where the issue originated in code, how it manifests in production, and the suggestion of how to fix the vulnerability. With Copilot Autofix and GitHub Copilot coding agent capabilities, AI-generated and validated fixes are suggested in real time – shortening remediation cycles from days to hours. For organizations, this integration delivers three tangible benefits: Collaborate without friction. Security teams can open and track GitHub issues directly from Defender for Cloud with context and vulnerability details, ensuring shared visibility between security and development. Accelerate remediation with AI. Copilot-assisted fixes make it faster and safer to resolve vulnerabilities without breaking developer flow. Prioritize what matters most. By mapping runtime threats directly to their source in code, teams can focus on vulnerabilities that are truly exploitable – not just theoretical. Together, security, development, and AI now move as one, finding and fixing issues faster and creating a continuous feedback loop that learns from runtime, feeds insights back into development, and redefines how secure apps and agents get built in the age of AI. Unified posture management and threat protection extends to secure AI Agents The next frontier is securing the AI agents teams create – ensuring protection evolves as fast as the intelligence driving them. IDC projects that organizations will deploy 1.3 billion AI agents by 2028 2 , each capable of reasoning, acting, and accessing sensitive data across multiple environments. As these systems scale, visibility becomes the first challenge: knowing what agents exist, what data they touch, and where risks connect. And with 66% of organizations 3 planning to establish a formal AI risk management function within the next four years, it’s clear that security leaders are racing to catch up with this next evolution. To help organizations stay ahead, Microsoft Defender now provides unified posture management and threat protection for AI agents as a part of Microsoft Agent 365 (in preview). These first-of-its-kind capabilities that secure agentic AI applications across their entire lifecycle. With this innovation, Defender helps organizations secure AI agents in three critical ways: Comprehensive visibility for AI Agents. Gain unified visibility and management of AI agents through Defender, spanning both pro-code and low-code environments from Microsoft Foundry to Copilot Studio. With a single agent inventory, teams can see where agents run and what they connect to – reducing shadow AI and agent sprawl. Risk reduction through posture management. Proactively strengthen AI agents’ security posture with Defender’s posture recommendations and attack path analysis for AI agents. These insights reveal how weak links across agents and cloud resources can form broader risks, helping teams detect and address vulnerabilities before they lead to incidents. Threat protection for AI Agents. Detect, investigate, and respond to threats targeting agentic AI services across models, agents from Microsoft Copilot Studio and Microsoft Foundry, and cloud applications using Defender’s AI-specific detection analytics. These include scenarios like prompt injection, sensitive data exposure, or malicious tool misuse, all enriched with Microsoft’s unmatched threat intelligence for deeper context and faster response. By embedding security into every layer of the agentic AI lifecycle, Defender helps organizations start secure and stay secure. This unified approach ensures that as AI agents evolve and scale, protection scales with them, anchoring the same continuous security foundation that extends across code, cloud, and beyond. Cloud posture management extends to secure serverless resources Defender for Cloud’s unified foundation extends beyond agents – to the cloud infrastructure and platforms that power them – rounding out the protection that scales with innovation itself. That innovation is increasingly running on serverless computing, now a core layer of cloud-native and AI-powered application development. It gives teams the speed and simplicity to deliver faster, but also expands the attack surface across multicloud environments with new exposure points, from unsecured functions to lateral movement risks. To help organizations secure this expanding layer, Microsoft Defender for Cloud is extending its Cloud Security Posture Management (CSPM) to serverless compute and application platforms (available in preview by end of November). With this new coverage, security teams gain greater visibility into serverless compute environments and application platforms, including Azure Functions, Azure Web Apps, and AWS Lambda. Defender for Cloud integrates serverless posture insights into attack path analysis, helping security teams identify and visualize risk, continuously monitor and detect misconfigurations, and find vulnerable serverless resources – further strengthening security posture across the modern application lifecycle. This extension brings serverless computing into the same unified protection model that already secures code, containers, and workloads in Defender for Cloud. As customers modernize with event-driven architectures, Defender for Cloud evolves with them, delivering consistent visibility, control, and protection across every layer of the cloud. Deeper expansion into the Defender Portal turns fragmentation into focus Finally, bringing all the signals security teams depend on into one place requires a single operational hub – a unified security experience that delivers clarity at scale. Yet with 89% of organizations operating across multiple clouds 4 and using an average of 10 security tools to protect them 5 , teams struggle to manage risk across fragmented dashboards and disjointed data – slowing detection and response and leaving blind spots that attackers can exploit. To help security teams move faster and act with clarity, we’re announcing the public preview of unified cloud security posture management into the Microsoft Defender security portal. With Microsoft Defender for Cloud’s deep integration into the unified portal, we eliminate security silos and bring a modern, streamlined experience that is more intuitive and purpose-built for today’s security teams. With this deep integration, Microsoft delivers three key advancements: A new Cloud Security dashboard that unifies posture management and threat protection, giving security teams a complete view of their multicloud environment in one place. Integrated posture capabilities within Exposure Management. Security teams can now see assets, vulnerabilities, attack paths, secure scores, and prioritized recommendations in a single pane of glass, focusing on the issues that matter most. A centralized asset inventory that consolidates resources across Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP), enabling posture validation, logical segmentation, and simplified visibility aligned to operational needs. To complement these capabilities, granular role-based access control (RBAC) helps reduce operational risk and simplify compliance across multicloud environments. The Microsoft Defender portal is now the center of gravity for security teams – bringing together cloud, endpoint and identity protection into one connected experience. Looking ahead, customers will soon be able to onboard and secure new resources directly within the Defender portal, streamlining setup and accelerating time to value. Large organizations will also gain the ability to manage multiple tenants from this unified experience as the rollout expands. The Azure portal remains essential for Defender for Cloud personas beyond security teams, such as DevOps. Adding new resource coverage will continue in the Azure portal as part of this transition. We’ll also keep enhancing experiences for IT and operations personas as part of our broader vision, read more on that in the latest news here. Ready to explore more? To learn more about Defender for Cloud and our latest innovations, you can: Join us at Ignite breakout sessions: Secure what matters with a unified cloud security strategy Secure code to cloud with AI infused DevSecOps Secure your applications: Unified Visibility and Posture Management AI-powered defense for cloud workloads Check out our cloud security solution page and Defender for Cloud product page. New IDC research reveals a major cloud security shift – read the full blog to understand what it means for your organization. Start a 30-day free trial. 1: Source: State of the Developer Nation Report 2: Source: IDC Info Snapshot, Sponsored by Microsoft, 1.3 Billion AI Agents by 2028, Doc. #US53361825, May 2025 3: Source: According to KPMG, 66% of firms who don’t have a formalized AI risk management function are aiming to do so in the next 1-4 years. 4: Source: Flexera 2024 State of the Cloud Report 5: Source: IDC White Paper, Sponsored by Microsoft, "THE NEXT ERA OF CLOUD SECURITY: Cloud-Native Application Protection Platform and Beyond", Doc. #US53297125, April 2025
Automate DevOps Security in Defender for Cloud Recommendation Remediation
Automate DevOps Security in Defender for Cloud Recommendation Remediation Logic Apps are a workflow automation feature of Microsoft Defender for Cloud in which you can create and run automated workflows that integrate your apps, data, services, and systems. This blog walks through creating a Logic App that you can use to auto-remediate the DevOps security recommendation in Defender for Cloud called “GitHub repositories should have Dependabot scanning enabled” by enabling Dependabot on a GitHub repo. Security Operators will find this Logic App particularly useful because they do not need to be familiar with GitHub or login to GitHub to enable Dependabot scanning. Instead, SecOps can enable Dependabot open source dependency scanning remotely and on numerous repositories by using Logic App automation. Objectives: Create a Logic App to enable Dependabot in GitHub Create a PAT Token and secure it in Azure Key Vault Test the Logic App Prerequisites: Key Vault – for Personal Access Token secret Connector provisioned in MDC to your GitHub Source Code Management System Sample GitHub repository – with Dependabot disabled Create a Logic App to enable Dependabot on a GitHub repo Login to Azure and search for or click Logic Apps Click + Add Choose a Subscription and Resource group Enter a name for your Logic App Under Plan, choose Consumption Click Review + create Click Create Go to the Logic App you created and click Logic app designer in the left menu Click Blank Logic App In the search box, type Recommendation Choose When a Microsoft Defender for Cloud Recommendation is created or triggered Click + New step Type variable in the search box Choose Initialize variable For Name, type repo_name For Type, choose String Click + New step Type variable in the search box Choose Initialize variable For Name, type owner For Type, choose String Click + New step Type variable in the search box Choose Set variable For Name, choose repo_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),12)) and click OK Click + New step Type variable in the search box Choose Set variable For Name, choose owner from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),10)) and click OK For this Logic App to execute securely, you need a Personal Access Token (PAT) to use in the API request. Follow the steps here in the GitHub documentation to create a PAT: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token Important: The PAT needs permissions to enable Dependabot—which requires Full control of private repositories After you create a PAT, this should be stored in a Key Vault to keep it secure and accessible by the Logic App. Add the PAT as a secret to your Key Vault. Click Save on the Logic App canvas. Navigate back to the Logic App Click Identity On the System assigned tab, set status to On Click Save, then Yes Click Azure role assignments Click + Add role assignment In Scope, choose Key Vault. In Subscription, choose the subscription with your Key Vault. In Resource, select the Key Vault. In Role, choose Key Vault Reader Click Save Navigate back to the Logic App Click Identity On the System assigned tab, copy the Object (principal) ID Navigate to your Key Vault Click Access policies Click + Create In the Secret permissions list, tick Get and List Click Next Paste the Object (principal) ID that you copied earlier in the Search by box Click the Identity and click Next Click Next, then click Create Click Add, then click Save Navigate back to the Logic App Click Edit to go to the Logic Apps Designer Click + New step Type key vault in the search box Choose Azure Key Vault, click Get secret Click Connect with managed identity Type a Connection name, then type your Key Vault name in the Vault name box Click Create Choose your secret from the Name of the secret dropdown list Click + New step Type HTTP in the search box and click HTTP In Method, choose PUT. In URI, type https://api.github.com/repos///vulnerability-alerts. Put your cursor after repos/ and in the dynamic content click owner Move after the next / and click repo_name from the dynamic content In Headers, for Enter key type Accept and for Enter value type application/vnd.github+json In Headers, for Enter key type Authorization and for Enter value type token <space> click Value in the dynamic content Your HTTP step should now look like the following: Click Save to save the workflow Your no code Logic App is now complete and needs to be tested. Test the Logic App Navigate to Microsoft Defender for Cloud Click Recommendations Expand Enable enhanced security features, click GitHub repositories should have Dependabot enabled Expand Affected resources, tick a GitHub repository Click Trigger logic app In the Selected subscription dropdown, choose the Subscription that contains the Logic App Tick the box next to the Logic app Click Trigger Now let’s verify that Dependabot has been enabled Navigate to the GitHub repository that did not have Dependabot enabled Click Settings Click Code security and analysis You should now see that Dependabot alerts is enabled Conclusion To review, we’ve walked through creating a Logic App to auto-remediate the MDC recommendation: “GitHub repositories should have Dependabot scanning enabled” by enabling Dependabot on a GitHub repo. This helps harden the security on your organization’s GitHub repositories and provides Security Operators with visibility into your organization’s open source dependencies via Dependabot scanning findings. Additional Resources To learn more about DevOps security, read this documentation Download (free) a special Appendix about DevOps security from the latest Microsoft Defender for Cloud book published by Microsoft Press To learn how to onboard your GitHub Source Code Management System to Defender for Cloud, read this documentation for GitHubAutomate SecOps to Developer Communication with DevOps Security in Defender for Cloud
Automate SecOps to Developer Communication with DevOps Security in Defender for Cloud Logic Apps are a workflow automation feature of Microsoft Defender for Cloud (MDC) in which you can create and run automated workflows that integrate your apps, data, services, and systems. Customer feedback has been loud and clear—Security Teams need more efficient and effective ways to communicate directly with Development Teams about discovered security findings. This blog walks through creating a Logic App that Security Teams can use to automate communication of discovered security issues to Development Teams. The Logic App creates a Work Item in Azure DevOps (ADO) containing repository location, description, and remediation information from DevOps security in Defender for Cloud Recommendations that Developers can use to remediate the discovered security issue. Security Operators will find this Logic App particularly useful because they do not need to be familiar with Azure DevOps or even to login to Azure DevOps to create a Work Item for their Developers. Instead, SecOps can trigger a Logic App on an affected repository and create a Work Item for a Development Team to triage and remediate. Objectives: Create a Logic App to create an Azure DevOps work item from an MDC Recommendation Test the Logic App Prerequisite: Connector provisioned in MDC to your Source Code Management System (such as Azure DevOps or GitHub) Create a Logic App to Create an ADO Work Item Login to Azure and search for or click Logic Apps Click + Add Choose a Subscription and Resource group Enter a name for your Logic App Under Plan, choose Consumption Click Review + create Click Create Go to the Logic App you created and click Logic app designer in the left menu Click Blank Logic App In the search box, type Recommendation Choose When a Microsoft Defender for Cloud Recommendation is created or triggered Click + New step Type variable in the search box Choose Initialize variable For Name, type org_name For Type, choose String Click + New step Type variable in the search box Choose Initialize variable For Name, type project_name For Type, choose String Click + New step Type variable in the search box Choose Initialize variable For Name, type repo_name For Type, choose String Click + New step Type variable in the search box Choose Set variable For Name, choose org_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),10)) and click OK Click + New step Type variable in the search box Choose Set variable For Name, choose project_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),12)) and click OK Click + New step Type variable in the search box Choose Set variable For Name, choose repo_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),14)) and click OK Click + New step Type azure devops in the search box Click Create a work item Click Sign in Click Accept to allow the App request for the Logic App to write to Azure DevOps For Organization Name, click in the box, click Enter custom value In the Add dynamic content flyout, click org_name For Project name, click Enter custom value In the Add dynamic content flyout, click project_name For Work Item Type, type task For Title, click in the box, type the title of the work item you want to create for your Developers, such as: A security issue needs to be remediated from the following repo: In the Add dynamic content flyout, click repo_name For Description, type Description: In the Add dynamic content flyout, click Properties Metadata Description, then hit enter twice Type Remediation steps: then hit enter In the Add dynamic content flyout, click Properties Metadata Remediation Description Your Logic App should now look like the following: Your no code Logic App is now complete and needs to be tested. Test the Logic App Navigate to Microsoft Defender for Cloud Click Recommendations Expand Remediate vulnerabilities, click Code repositories should have secret scanning findings resolved Expand Affected resources, tick an Azure DevOps repository Click Trigger logic app In the Selected subscription dropdown, choose the Subscription that contains the Logic App Tick the box next to the Logic app Click Trigger Now let’s verify that your work item has been created Login to Azure DevOps and navigate to the Project with the repository you tested Click Boards, then click Work items to see the work item that you created Your work item should look similar to the following work item: Conclusion To review, we’ve walked through creating a Logic App that creates a Work Item in Azure DevOps to communicate with Developers so they can remediate security findings discovered by Microsoft Defender for Cloud. This Logic App can be executed on any Azure DevOps repository. It injects the location, description, and remediation steps in the Work Item description body so that Developers can quickly find and fix the security issue. This helps Security Operators automate communication with Developers by creating a Work Item that the Development Team can then prioritize in their Sprint Planning sessions. Additional Resources To learn more about DevOps security in Defender for Cloud, read this documentation Download (free) a special Appendix about DevOps security in Defender for Cloud from the latest Microsoft Defender for Cloud book published by Microsoft Press To learn how to onboard your Azure DevOps Source Code Management System to Defender for Cloud, read this documentation for Azure DevOps
