Security recommendations for DevOps resources
This article lists the recommendations you might see in Microsoft Defender for Cloud if you connect an Azure DevOps, GitHub, or GitLab environment by using the Environment settings page. The recommendations that appear in your environment are based on the resources that you're protecting and on your customized configuration.
To learn about actions that you can take in response to these recommendations, see Remediate recommendations in Defender for Cloud.
Learn more about DevOps security benefits and features.
DevOps recommendations don't affect your secure score. To decide which recommendations to resolve first, look at the severity of each recommendation and its potential impact on your secure score.
DevOps recommendations
Azure DevOps recommendations
Azure DevOps repositories should have GitHub Advanced Security for Azure DevOps (GHAzDO) enabled
Description: 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.
Severity: High
Azure DevOps repositories should have secret scanning findings resolved
Description: 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.
Severity: High
Azure DevOps repositories should have code scanning findings resolved
Description: Vulnerabilities were found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities.
Severity: Medium
Azure DevOps repositories should have dependency vulnerability scanning findings resolved
Description: Dependency vulnerabilities have been found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities.
Severity: Medium
Azure DevOps repositories should have infrastructure as code scanning findings resolved
Description: 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.
Severity: Medium
Azure DevOps build pipelines shouldn't have secrets available to builds of forks
Description: 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.
Severity: High
Azure DevOps service connections shouldn't grant access to all pipelines
Description: 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.
Severity: High
Azure DevOps secure files shouldn't grant access to all pipelines
Description: 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.
Severity: High
Azure DevOps variable groups with secret variables shouldn't grant access to all pipelines
Description: 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.
Severity: High
Azure DevOps Classic Azure service connections shouldn't be used to access a subscription
Description: 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.
Severity: Medium
GitHub recommendations
GitHub repositories should have secret scanning enabled
Description: 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.
Severity: High
GitHub repositories should have code scanning enabled
Description: 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.
Severity: Medium
GitHub repositories should have Dependabot scanning enabled
Description: 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.
Severity: Medium
GitHub repositories should have secret scanning findings resolved
Description: 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.
Severity: High
GitHub repositories should have code scanning findings resolved
Description: Vulnerabilities have been found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities.
Severity: Medium
GitHub repositories should have dependency vulnerability scanning findings resolved
Description: GitHub repositories should have dependency vulnerability scanning findings resolved.
Severity: Medium
GitHub repositories should have infrastructure as code scanning findings resolved
Description: 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.
Severity: Medium
GitHub repositories should have protection policies for default branch enabled
Description: 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.
Severity: High
GitHub repositories should have force pushes to default branch disabled
Description: 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.
Severity: Medium
GitHub organizations should have secret scanning push protection enabled
Description: 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.
Severity: High
GitHub repositories shouldn't use self hosted runners
Description: 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.
Severity: High
GitHub organizations should have actions workflow permissions set to read-only
Description: 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.
Severity: High
GitHub organizations should have more than one person with administrator permissions
Description: Having at least two administrators reduces the risk of losing admin access. This is useful in case of break-glass account scenarios.
Severity: High
GitHub organizations should have base permissions set to no permissions or read
Description: Base permissions should be set to none or read for an organization to follow the principle of least privilege and prevent unnecessary access.
Severity: High
(Preview) GitHub repositories should have API security testing findings resolved
Description: 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.
Severity: Medium
GitLab recommendations
GitLab projects should have secret scanning findings resolved
Description: 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.
Severity: High
GitLab projects should have code scanning findings resolved
Description: Vulnerabilities have been found in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities.
Severity: Medium
GitLab projects should have dependency vulnerability scanning findings resolved
Description: GitHub repositories should have dependency vulnerability scanning findings resolved.
Severity: Medium
GitLab projects should have infrastructure as code scanning findings resolved
Description: 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.
Severity: Medium
Deprecated DevOps security recommendations
Code repositories should have code scanning findings resolved
Description: 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)
Severity: Medium
Code repositories should have secret scanning findings resolved
Description: 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 might not reflect the complete status of secrets in your repositories. (No related policy)
Severity: High
Code repositories should have Dependabot scanning findings resolved
Description: 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)
Severity: Medium
Code repositories should have infrastructure as code scanning findings resolved
Description: 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)
Severity: Medium
GitHub repositories should have code scanning enabled
Description: 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)
Severity: Medium
GitHub repositories should have secret scanning enabled
Description: 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)
Severity: High
GitHub repositories should have Dependabot scanning enabled
Description: 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)
Severity: Medium
Related content
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for