Security recommendations for DevOps resources - a reference guide
This article lists the recommendations you might see in Microsoft Defender for Cloud if you've connected an Azure DevOps, GitHub, or GitLab environment from the Environment settings page. The recommendations shown in your environment depend on the resources you're protecting and your customized configuration.
To learn about how to respond to these recommendations, see Remediate recommendations in Defender for Cloud.
Learn more about DevOps security benefits and features.
DevOps recommendations do not affect the Secure score. To prioritize recommendations, consider the number of impacted resources, the total number of findings and the level of severity.
DevOps recommendations
Azure DevOps recommendations
| Recommendation | Description | Severity |
|---|---|---|
| Azure DevOps repositories should have GitHub Advanced Security for Azure DevOps (GHAzDO) enabled | DevOps security in Defender for Cloud uses a central console to empower security teams with the ability to protect applications and resources from code to cloud across Azure DevOps. With enablement of GitHub Advanced Security for Azure DevOps (GHAzDO) repositories includes GitHub Advanced Security for Azure DevOps you get findings about secrets, dependencies, and code vulnerabilities in your Azure DevOps repositories surfaced in Microsoft Defender for Cloud. | High |
| Azure DevOps repositories should have secret scanning findings resolved | Secrets were found in code repositories. Remediate immediately to prevent a security breach. Secrets found in repositories can be leaked or discovered by adversaries, leading to compromise of an application or service. Note: The Microsoft Security DevOps credential scanning tool only scans builds on which it is configured to run. Therefore, results might not reflect the complete status of secrets in your repositories. | High |
| Azure DevOps repositories should have code scanning findings resolved | Vulnerabilities were found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. | Medium |
| Azure DevOps repositories should have dependency vulnerability scanning findings resolved | Dependency vulnerabilities have been found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. | Medium |
| Azure DevOps repositories should have infrastructure as code scanning findings resolved | Infrastructure as code security configuration issues have been found in repositories. The issues shown below have been detected in template files. To improve the security posture of the related cloud resources, it is highly recommended to remediate these issues. | Medium |
| Azure DevOps build pipelines shouldn't have secrets available to builds of forks | In public repositories, it's possible that people from outside the organization create forks and run builds on the forked repository. In such a case, if this setting is enabled, outsiders can get access to build pipeline secrets that were meant to be internal. | High |
| Azure DevOps service connections shouldn't grant access to all pipelines | Service connections are used to create connections from Azure Pipelines to external and remote services for executing tasks in a job. Pipeline permissions control which pipelines are authorized to use the service connection. To support security of the pipeline operations, service connections shouldn't be granted access to all YAML pipelines. This helps to maintain the principle of least privilege because a vulnerability in components used by one pipeline can be leveraged by an attacker to attack other pipelines having access to critical resources. | High |
| Azure DevOps secure files shouldn't grant access to all pipelines | Secure files give developers a way to store files that can be shared across pipelines. These files are typically used to store secrets such as signing certificates and SSH keys. If a secure file is granted access to all YAML pipelines, an unauthorized user can steal information from the secure files by building a YAML pipeline and accessing the secure file. | High |
| Azure DevOps variable groups with secret variables shouldn't grant access to all pipelines | Variable groups store values and secrets that you might want to be passed into a YAML pipeline or make available across multiple pipelines. You can share and use variable groups in multiple pipelines in the same project. If a variable group containing secrets is marked as accessible to all YAML pipelines, then an attacker can exploit the assets involving the secret variables by creating a new pipeline. | High |
| Azure DevOps Classic Azure service connections shouldn't be used to access a subscription | Use the Azure Resource Manager (ARM) type of service connections instead of Azure Classic service connections to connect to Azure subscriptions. The ARM model offers multiple security enhancements, including stronger access control, improved auditing, ARM-based deployment/governance, access to managed identities and key vault for secrets, Entra Permissions-based authentication, and support for tags and resource groups for streamlined management. | Medium |
GitHub recommendations
| Recommendation | Description | Severity |
|---|---|---|
| GitHub repositories should have secret scanning enabled | GitHub scans repositories for known types of secrets, to prevent fraudulent use of secrets that were accidentally committed to repositories. Secret scanning will scan the entire Git history on all branches present in the GitHub repository for any secrets. Examples of secrets are tokens and private keys that a service provider can issue for authentication. If a secret is checked into a repository, anyone who has read access to the repository can use the secret to access the external service with those privileges. Secrets should be stored in a dedicated, secure location outside the repository for the project. | High |
| GitHub repositories should have code scanning enabled | GitHub uses code scanning to analyze code in order to find security vulnerabilities and errors in code. Code scanning can be used to find, triage, and prioritize fixes for existing problems in your code. Code scanning can also prevent developers from introducing new problems. Scans can be scheduled for specific days and times, or scans can be triggered when a specific event occurs in the repository, such as a push. If code scanning finds a potential vulnerability or error in code, GitHub displays an alert in the repository. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project. | Medium |
| GitHub repositories should have Dependabot scanning enabled | GitHub sends Dependabot alerts when it detects vulnerabilities in code dependencies that affect repositories. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project or other projects that use its code. Vulnerabilities vary in type, severity, and method of attack. When code depends on a package that has a security vulnerability, this vulnerable dependency can cause a range of problems. | Medium |
| GitHub repositories should have secret scanning findings resolved | Secrets have been found in code repositories. This should be remediated immediately to prevent a security breach. Secrets found in repositories can be leaked or discovered by adversaries, leading to compromise of an application or service. | High |
| GitHub repositories should have code scanning findings resolved | Vulnerabilities have been found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. | Medium |
| GitHub repositories should have dependency vulnerability scanning findings resolved | GitHub repositories should have dependency vulnerability scanning findings resolved | Medium |
| GitHub repositories should have infrastructure as code scanning findings resolved | Infrastructure as code security configuration issues have been found in repositories. The issues shown below have been detected in template files. To improve the security posture of the related cloud resources, it is highly recommended to remediate these issues. | Medium |
| GitHub repositories should have protection policies for default branch enabled | The default branch of the repository should be protected via branch protection policies to prevent unintended/malicious changes from being directly committed to the repository. | High |
| GitHub repositories should have force pushes to default branch disabled | As the default branch is typically used for deployment and other privileged activities, any changes to it should be approached with caution. Enabling force pushes can introduce unintended or malicious changes to the default branch. | Medium |
| GitHub organizations should have secret scanning push protection enabled | Push Protection will block commits that contain secrets thus preventing accidental exposure of secrets. To avoid the risk of credential exposure, Push Protection should be automatically enabled for every secret scanning enabled repository. | High |
| GitHub repositories shouldn't use self hosted runners | Self-Hosted Runners on GitHub lack guarantees of operation in ephemeral clean virtual machines and can be persistently compromised by untrusted code in a workflow. As such, Self-Hosted Runners shouldn't be utilized for action workflows. | High |
| GitHub organizations should have actions workflow permissions set to read-only | By default, Action workflows should be granted read-only permissions to prevent malicious users from exploiting over-permissioned workflows to access and tamper with resources. | High |
| GitHub organizations should have more than one person with administrator permissions | Having at least two administrators reduces the risk of losing admin access. This is useful in case of break-glass account scenarios. | High |
| GitHub organizations should have base permissions set to no permissions or read | Base permissions should be set to none or read for an organization to follow the principle of least privilege and prevent unnecessary access. | High |
| (Preview) GitHub repositories should have API security testing findings resolved | API security vulnerabilities have been found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. | Medium |
GitLab recommendations
| Recommendation | Description | Severity |
|---|---|---|
| GitLab projects should have secret scanning findings resolved | Secrets have been found in code repositories. This should be remediated immediately to prevent a security breach. Secrets found in repositories can be leaked or discovered by adversaries, leading to compromise of an application or service. | High |
| GitLab projects should have code scanning findings resolved | Vulnerabilities have been found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. | Medium |
| GitLab projects should have dependency vulnerability scanning findings resolved | GitHub repositories should have dependency vulnerability scanning findings resolved | Medium |
| GitLab projects should have infrastructure as code scanning findings resolved | Infrastructure as code security configuration issues have been found in repositories. The issues shown below have been detected in template files. To improve the security posture of the related cloud resources, it is highly recommended to remediate these issues. | Medium |
Deprecated recommendations
| Recommendation | Description | Severity |
|---|---|---|
| Code repositories should have code scanning findings resolved | DevOps security in Defender for Cloud has found vulnerabilities in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. (No related policy) | Medium |
| Code repositories should have secret scanning findings resolved | DevOps security in Defender for Cloud has found a secret in code repositories. This should be remediated immediately to prevent a security breach. Secrets found in repositories can be leaked or discovered by adversaries, leading to compromise of an application or service. For Azure DevOps, the Microsoft Security DevOps CredScan tool only scans builds on which it has been configured to run. Therefore, results may not reflect the complete status of secrets in your repositories. (No related policy) | High |
| Code repositories should have Dependabot scanning findings resolved | DevOps security in Defender for Cloud has found vulnerabilities in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. (No related policy) | Medium |
| Code repositories should have infrastructure as code scanning findings resolved | DevOps security in Defender for Cloud has found infrastructure as code security configuration issues in repositories. The issues shown below have been detected in template files. To improve the security posture of the related cloud resources, it is highly recommended to remediate these issues. (No related policy) | Medium |
| GitHub repositories should have code scanning enabled | GitHub uses code scanning to analyze code in order to find security vulnerabilities and errors in code. Code scanning can be used to find, triage, and prioritize fixes for existing problems in your code. Code scanning can also prevent developers from introducing new problems. Scans can be scheduled for specific days and times, or scans can be triggered when a specific event occurs in the repository, such as a push. If code scanning finds a potential vulnerability or error in code, GitHub displays an alert in the repository. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project. (No related policy) | Medium |
| GitHub repositories should have secret scanning enabled | GitHub scans repositories for known types of secrets, to prevent fraudulent use of secrets that were accidentally committed to repositories. Secret scanning will scan the entire Git history on all branches present in the GitHub repository for any secrets. Examples of secrets are tokens and private keys that a service provider can issue for authentication. If a secret is checked into a repository, anyone who has read access to the repository can use the secret to access the external service with those privileges. Secrets should be stored in a dedicated, secure location outside the repository for the project. (No related policy) | High |
| GitHub repositories should have Dependabot scanning enabled | GitHub sends Dependabot alerts when it detects vulnerabilities in code dependencies that affect repositories. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project or other projects that use its code. Vulnerabilities vary in type, severity, and method of attack. When code depends on a package that has a security vulnerability, this vulnerable dependency can cause a range of problems. (No related policy) | Medium |
Next steps
To learn more about recommendations, see the following:
Feedback
Submit and view feedback for