Compliance for Exposed Secrets Discovered by DevOps Security in Defender for Cloud
Azure Policy helps enforce organizational standards and assess compliance at-scale. You can now create a custom Azure Policy to add DevOps security to your centralized compliance dashboards. This blog walks through creating a custom Azure Policy that leverages the DevOps security recommendations in Defender for Cloud called “Azure DevOps repositories should have secret scanning findings should be resolved", "GitHub repositories should have secret scanning findings resolved", and "GitLab projects should have secret scanning findings resolved". This policy gives Security and Compliance Teams visibility into discovered secrets found in Azure DevOps, GitHub, and GitLab that have been onboarded to Microsoft Defender for Cloud.
Create a custom AuditIfNotExist Azure Policy
Visualize the custom policy in the Compliance view in Azure Policy
Connector provisioned in Defender for Cloud to your Source Code Management System (such as Azure DevOps, GitHub, or GitLab)
For Azure DevOps: enable secret scanning in GitHub Advanced Security for Azure DevOps
For GitHub: enable secret scanning in GitHub Advanced Security
For GitLab: enable secret scanning in GitLab Ultimate
Create a Custom Azure Compliance Policy for Exposed Secrets
Navigate to Azure Policy
Click + Policy definition
For Definition location, choose a subscription or management group
For Name, type code repositories should have secret scanning findings resolved
Type a Description, such as: DevOps security in Defender for Cloud has found a secret in code repositories. This should be remediated immediately to prevent a security breach.
For Category, click Create new, then type DevOps Security
For Policy Rule, cut and paste the following JSON:
Note: The example above is for Azure DevOps. To replicate the same policy for GitHub or GitLab:
Change "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" to "microsoft.security/securityconnectors/devops/githubowners/repos"
Change assessment key name "b5ef903f-8655-473b-9784-4f749eeb25c6" to "dd98425c-1407-40cc-8a2c-da5d0a2f80da"
Change "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" to "microsoft.security/securityconnectors/devops/gitlabgroups/projects"
Change assessment key name "b5ef903f-8655-473b-9784-4f749eeb25c6" to "867001c3-2d01-4db7-b513-5cb97638f23d"
For more information on Azure Policy definition structure, effects, scope, and more, review this documentation.
The policy we just created uses the assessment ID for the Defender for Cloud DevOps securirty recommendation called “Code repositories should have secret scanning findings resolved” to determine whether there are any resources that are not NotApplicable or Healthy. If the policy finds an Unhealthy status code, that repository will be flagged as non-compliant because a secret was discovered.
Navigate to Azure Policy
Click Assign Policy
For Scope, choose the subscription that has your connector or a top-level management group
For Policy definition, choose code repositories should have secret scanning findings resolved
Click Review + create
Find the policy and click on it to view details
The custom Policy gives you reporting capabilities on both compliant and non-compliant repositories.
It should look like the following in the Policy Compliance details:
To review, we’ve walked through setting up a custom Azure Policy to audit repositories against a Defender for Cloud assessment that finds exposed secrets. We assigned the policy to a subscription and visualized the results in Azure Policy’s centralized Compliance view. This helps Compliance Managers, Security Operators, and Governance Teams identify non-compliant repositories across connected DevOps environments. You can then use Azure Policy reporting on these discovered secrets to implement governance for resource consistency, regulatory compliance, security, and management.