Common questions about Defender for DevOps

If you want to scan specific folders in Azure DevOps repos with CredScan, you can use:

env: 
  credscan_targetdirectory: 'NameOfFolderToScanForSecrets/'

A full ADO YAML file for a pipeline that does CredScan scanning for secrets on a specific folder could look like this:

trigger:
  branches:
    include:
      - main
      - master

pool:
  vmImage: "windows-latest"

steps:
  - task: MicrosoftSecurityDevOps@1
    displayName: "Microsoft Security DevOps"
    inputs:
      categories: 'secrets' 
      break: false
    env:
      credscan_targetdirectory: 'NameOfFolderToScanForSecrets/'

When you select the Authorize button, the account that you're logged in with is used. That account can have the same email but may have a different tenant. Make sure you have the right account/tenant combination selected in the popup consent screen and Visual Studio.

You can check which account is signed in.

The Azure DevOps service only supports TfsGit.

Ensure that you've onboarded your repositories to Microsoft Defender for Cloud. If you still can't see your repository, ensure that you're signed in with the correct Azure DevOps organization user account. Your Azure subscription and Azure DevOps Organization need to be in the same tenant. If the user for the connector is wrong, you need to delete the previously created connector, sign in with the correct user account and re-create the connector.

To ensure your code is scanned for secrets, make sure you've onboarded your repositories to Defender for Cloud.

In addition to onboarding resources, you must have the Microsoft Security DevOps (MSDO) Azure DevOps extension configured for your pipelines. The extension runs secret scan along with other scanners.

If no secrets are identified through scans, the total exposed secret for the resource shows Healthy in Defender for Cloud.

If secret scan isn't enabled (meaning MSDO isn't configured for your pipeline) or a scan isn't performed for at least 14 days, the resource shows as N/A in Defender for Cloud.

If you don’t see SARIF file in the expected path, you may have chosen a different drop path than the CodeAnalysisLogs/msdo.sarif one. Currently you should drop your SARIF files to CodeAnalysisLogs/msdo.sarif.

When you use classic pipeline configuration, make sure you don't change artifact name. This can result not seeing the results for your project.

Currently, OSS vulnerability findings are only available for GitHub repositories. Azure DevOps repositories will have the total exposed secrets, IaC misconfigurations, and code security findings available. It will show N/A for OSS vulnerabilities. You can learn more about how to Review your findings.

For a previously unhealthy scan result to be healthy again, updated healthy scan results need to be from the same build definition as the one that generated the findings in the first place. A common scenario where this issue occurs is when testing with different pipelines. For results to refresh appropriately, scan results need to be for the same pipeline(s) and branch(es).

If no scan is performed for 14 days, the scan results revert to N/A.

Ensure that you've onboarded the project with the connector and that your repository (that build is for), is onboarded to Microsoft Defender for Cloud. You can learn how to onboard your DevOps repository to Defender for Cloud.

You must have more than a stakeholder license to the repos to onboard them, and you need to be at least the security reader on the subscription where the connector is created. You can confirm if you've onboarded the repositories by seeing them in the inventory list in Microsoft Defender for Cloud.

We recommend navigating to the DevOps Security page to see an overview of your DevOps recommendations and posture. You can sort and filter by the repos you care about to dive into the recommendation details.

You can also view your DevOps recommendations on the Recommendations page. Navigate to Recommendations, select the "All recommendations" tab, and filter the environment by the relevant DevOps sources (e.g., AzureDevOps and/or GitHub).

Defender for DevOps connects to your source code management system, for example, Azure DevOps, GitHub, to provide a central console for your DevOps resources and security posture. Defender for DevOps processes and stores the following information:

• Metadata on your connected source code management systems and associated repositories. This data includes user, organizational, and authentication information.

• Scan results for recommendations and assessments results and details.

Data is stored within the region your connector is created in and flows into Microsoft Defender for Cloud. You should consider which region to create your connector in, for any data residency requirements as you design and create your DevOps connector.

Defender for DevOps currently doesn't process or store your code, build, and audit logs.

Learn more about Microsoft Privacy Statement.

Azure DevOps doesn't have the necessary granularity for its permissions. These permissions are required for some of the Defender for DevOps features, such as pull request annotations in order to work.

Exemptions aren't available for Defender for DevOps within Microsoft Defender for Cloud.

Ensure you are using the same Subscription ID for GHAzDO and Defender for Cloud. If you are still unable to see the results, the issue might be caused by your ADO connector lacking the necessary scope. Defender for DevOps introduced new scopes to ADO connectors in June. If you created the connector before June and haven't updated it, you won't be able to see GHAzDO results due to missing scope on the connector. You would need to create a new ADO connector, which will automatically include the new scopes.

Currently, scanning occurs at build time.

The ability to block developers from committing code with exposed secrets isn't currently available.

Make sure you have write (owner/contributor) access to the subscription. If you don't have this type of access today, you can get it through activating an Azure Active Directory role in PIM.

The following languages are supported by Defender for DevOps:

• Python
• JavaScript
• TypeScript

When you run the pipeline in Azure DevOps, you receive the following error: no such file or directory, scandir 'D:\a\_msdo\versions\microsoft.security.devops.cli'.

This error can be seen in the extensions job as well.

This error occurs if you're missing the dependency of dotnet6 in the pipeline's YAML file. DotNet6 is required to allow the Microsoft Security DevOps extension to run. Include this as a task in your YAML file to eliminate the error.

You can learn more about Microsoft Security DevOps.

For example, can I migrate the connector from the Central US region to the West Europe region?

We don’t support automatic migration for the Defender for DevOps connectors from one region to another at this time.

If you want to move a connector’s location, for example a GitHub or Azure DevOps connector, to be stored in a different region than the original one where the connector was created, the recommendation is to delete the existing connector and then to create another connector in the new region.

Yes, API calls made by Defender for Cloud count against the Azure DevOps Global consumption limit. Defender for Cloud makes calls on-behalf of the user who onboards the connector.

If your organization list is empty in the UI after you onboarded an Azure DevOps connector, you need to ensure that the organization in Azure DevOps is connected to the Azure tenant that has the user who authenticated the connector.

For information on how to correct this issue, check out the DevOps trouble shooting guide.

Yes, there is no limit to how many Azure DevOps repositories you can onboard to Defender for DevOps.

However, there are two main implications when onboarding large organizations – speed and throttling. The speed of discovery for your DevOps repositories is determined by the number of projects for each connector (approximately 100 projects per hour). Throttling can happen because Azure DevOps API calls have a global rate limit and we limit the calls for project discovery to use a small portion of overall quota limits.

Consider using an alternative Azure DevOps identity (i.e., an Organization Administrator account used as a service account) to avoid individual accounts from being throttled when onboarding large organizations. Below are some scenarios of when to use an alternate identity to onboard a Defender for DevOps connector:

• Large number of Azure DevOps Organizations and Projects (~500 Projects or more).
• Large number of concurrent builds which peak during work hours.
• Authorized user is a Power Platform user making additional Azure DevOps API calls, using up the global rate limit quotas.

Once you have onboarded the Azure DevOps repositories using this account and configured and ran the Microsoft Security DevOps Azure DevOps extension in your CI/CD pipeline, then the scanning results will appear near instantaneously in Microsoft Defender for Cloud.

Next steps

Learn more about Defender for Defender for DevOps