How does the autobuild step work in Github Advanced Security for Azure Devops?

Question

I have a yaml pipeline to do code scanning and dependency scanning with Github Advanced Security for Azure devops:

pool:
  vmImage: ubuntu-latest

steps:

- task: AdvancedSecurity-Codeql-Init@1
  inputs:
    languages: 'csharp'

- task: AdvancedSecurity-Codeql-Autobuild@1

- task: AdvancedSecurity-Dependency-Scanning@1

- task: AdvancedSecurity-Codeql-Analyze@1

I have a monorepo that contains 5 applications, all in the same repository.

How does the autobuild step work? What if I have multiple dotnet projects (multiple csproj and sln files). How does it know which one to build? Will it build all of them?

On the other hand, when I use a custom build to only build one of my monorepo projects:

- task: DotNetCoreCLI@2
  displayName: '.NET Restore'
  inputs:
    command: restore
    projects: ${{ variables.projectPath }}
    vstsFeed: 'MyCorpFeed'
    includeNuGetOrg: true


- task: DotNetCoreCLI@2
  displayName: '.NET Build'
  inputs:
    command: build
    projects: ${{ variables.projectPath }}
    arguments: '--configuration release'

In the output I also notice alerts for other .NET projects (that were not included in the build). Am I doing something wrong? Or is this normal behavior ?

Answer 1

How does the autobuild step work? What if I have multiple dotnet projects (multiple csproj and sln files). How does it know which one to build? Will it build all of them?

When dealing with a monorepo that contains multiple projects, the autobuild step attempts to build all the projects it can find. If you have multiple .NET projects (multiple csproj and sln files), the autobuild step will try to build all of them. This is because the autobuild step is designed to maximize the coverage of the CodeQL analysis.

In the output I also notice alerts for other .NET projects (that were not included in the build). Am I doing something wrong? Or is this normal behavior ?

This is expected behavior. The CodeQL analysis is not limited to just the projects that were built in the current pipeline run. It analyzes the entire codebase in the repository. Therefore, if there are issues in the other .NET projects in your repository, they will be flagged by the CodeQL analysis.

Please refer to the official doc Code Scanning for more detials.

Answer 2

In the output I also notice alerts for other .NET projects (that were not included in the build). Am I doing something wrong? Or is this normal behavior ?

For C#, every file that is compiled (passed into the csharp compiler) between the CodeQL Init and the CodeQL Analyze tasks will traced and analyzed. A single solution that builds the entire monorepo (each project) will provide the most comprehensive scan results. Individual CodeQL pipelines for each service should surface the same results given that they must compile/scan all the code that comprises the project. A common speed optimization is to create a solution filter to exclude demo code and unit tests for a CodeQL scan.

Just tried it out: The autobuild does NOT build all projects. Just the ones at "top" level. It doesn't appear to go into sub folders

CodeQL Autobuild is documented for each language on the GitHub docs "About autobuild for CodeQL"

How does autobuild handle private nuget feeds?

As of current, autobuild will run nuget restore + msbuild or dotnet restore + dotnet build commands. If the credentials are configured in the default locations for nuget.config available to a runner, the credentials will be used. If you setup the nuget feed prior to autobuild (nuget sources add / dotnet nuget add source), then it will use those as well as they are generally just updating the nuget.config. It may very well be a better idea to use the AzDO built in build tasks from your existing CI pipelines instead of the autobuilder - they are a bit more friendly to using a AzDO Artifacts NuGet feed.

What about dependency scanning? Is that one related to the projects that were built? –

This is a completely separate toolset, it runs by walking the filesystem and detecting the NuGet manifests along with packages/versions that were dynamically resolved by a NuGet restore via project.assets. Technical details around how it is detecting package manifests can be found here.