Configure and customize the build tasks

Note

Effective December 31, 2022, the Microsoft Security Code Analysis (MSCA) extension is retired. MSCA is replaced by the Microsoft Security DevOps Azure DevOps extension. Follow the instructions in Configure to install and configure the extension.

This article describes in detail the configuration options available in each of the build tasks. The article starts with the tasks for security code analysis tools. It ends with the post-processing tasks.

Anti-Malware Scanner task

Note

The Anti-Malware Scanner build task requires a build agent with Windows Defender enabled. Hosted Visual Studio 2017 and later provide such an agent. The build task won't run on the Visual Studio 2015 hosted agent.

Although signatures can't be updated on these agents, signatures should always be less than three hours old.

Details of task configuration are shown in the following screenshot and text.

In the Type list box of the screenshot, Basic is selected. Select Custom to provide command-line arguments that customize the scan.

Windows Defender uses the Windows Update client to download and install signatures. If signature update fails on your build agent, the HRESULT error code is likely coming from Windows Update.

For more information on Windows Update errors and their mitigation, see Windows Update error codes by component and the TechNet article Windows Update Agent - Error Codes.

For information about YAML configuration for this task, check our Anti-Malware YAML options

BinSkim task

Note

Before you can run the BinSkim task, your build must meet one of these conditions:

• Your build produces binary artifacts from managed code.
• You have binary artifacts committed that you want to analyze with BinSkim.

Details of task configuration are shown in the following screenshot and list.

• Set the build configuration to Debug so that .pdb debug files are produced. BinSkim uses these files to map issues in the output binaries back to source code.
• To avoid researching and creating your own command line:
  • In the Type list, select Basic.
  • In the Function list, select Analyze.
• In Target, enter one or more specifiers for a file, directory, or filter pattern. These specifiers resolve to one or more binaries to be analyzed:
  • Multiple specified targets must be separated by a semicolon (;).
  • A specifier can be a single file or contain wildcards.
  • Directory specifications must always end with \*.
  • Examples:

           *.dll;*.exe
           $(BUILD_STAGINGDIRECTORY)\*
           $(BUILD_STAGINGDIRECTORY)\*.dll;$(BUILD_STAGINGDIRECTORY)\*.exe;

• If you select Command Line in the Type list, you need to run binskim.exe:
  • Make sure the first arguments to binskim.exe are the verb analyze followed by one or more path specifications. Each path can be either a full path or a path relative to the source directory.
  • Multiple target paths must be separated by a space.
  • You can omit the /o or /output option. The output value is added for you or replaced.
  • Standard command-line configurations are shown as follows.

           analyze $(Build.StagingDirectory)\* --recurse --verbose
           analyze *.dll *.exe --recurse --verbose

Note

The trailing \* is important if you specify directories for the target.

For more information on BinSkim command-line arguments, rules by ID, or exit codes, see the BinSkim User Guide.

For information about YAML configuration for this task, check our BinSkim YAML options

Credential Scanner task

Details of task configuration are shown in the following screenshot and list.

Available options include:

• Display Name: Name of the Azure DevOps Task. The default value is Run Credential Scanner
• Tool Major Version: Available values include CredScan V2, CredScan V1. We recommend customers to use the CredScan V2 version.
• Output Format: Available values include TSV, CSV, SARIF, and PREfast.
• Tool Version: We recommend you select Latest.
• Scan Folder: The repository folder to be scanned.
• Searchers File Type: The options for locating the searchers file that is used for scanning.
• Suppressions File: A JSON file can suppress issues in the output log. For more information about suppression scenarios, see the FAQ section of this article.
• Verbose Output: Self-explanatory.
• Batch Size: The number of concurrent threads used to run Credential Scanner. The default value is 20. Possible values range from 1 through 2,147,483,647.
• Match Timeout: The amount of time in seconds to spend attempting a searcher match before abandoning the check.
• File Scan Read Buffer Size: The size in bytes of the buffer used while content is read. The default value is 524,288.
• Maximum File Scan Read Bytes: The maximum number of bytes to read from a file during content analysis. The default value is 104,857,600.
• Control Options > Run this task: Specifies when the task will run. Select Custom conditions to specify more complex conditions.
• Version: The build task version within Azure DevOps. This option isn't frequently used.

For information about YAML configuration for this task, check our Credential Scanner YAML options

Roslyn Analyzers task

Note

Before you can run the Roslyn Analyzers task, your build needs to meet these conditions:

• Your build definition includes the built-in MSBuild or VSBuild build task to compile C# or Visual Basic code. The analyzers task relies on the input and output of the built-in task to run the MSBuild compilation with Roslyn analyzers enabled.
• The build agent running this build task has Visual Studio 2017 version 15.5 or later installed, so that it uses compiler version 2.6 or later.

Details of task configuration are shown in the following list and note.

Available options include:

• Ruleset: Values are SDL Required, SDL Recommended, or your own custom rule set.
• Analyzers Version: We recommend you select Latest.
• Compiler Warnings Suppressions File: A text file with a list of warnings IDs that are suppressed.
• Control Options > Run this task: Specifies when the task will run. Choose Custom conditions to specify more complex conditions.

Note

• Roslyn Analyzers are integrated with the compiler and can be run only as part of csc.exe compilation. Hence, this task requires the compiler command that ran earlier in the build to be replayed or run again. This replay or run is done by querying Azure DevOps (formerly Visual Studio Team Services) for the MSBuild build task logs.

  There is no other way for the task to reliably get the MSBuild compilation command line from the build definition. We considered adding a freeform text box to allow users to enter their command lines. But then it would be hard to keep those command lines up-to-date and in sync with the main build.

  Custom builds require replaying the entire set of commands, not just compiler commands. In these cases, enabling Roslyn Analyzers isn't trivial or reliable.

• Roslyn Analyzers are integrated with the compiler. To be invoked, Roslyn Analyzers require compilation.

  This new build task is implemented by recompiling C# projects that were already built. The new task uses only the MSBuild and VSBuild build tasks in the same build or build definition as the original task. However, in this case the new task uses them with Roslyn Analyzers enabled.

  If the new task runs on the same agent as the original task, the new task's output overwrites the original task's output in the s sources folder. Although the build output is the same, we advise that you run MSBuild, copy output to the the artifacts staging directory, and then run Roslyn Analyzers.

For additional resources for the Roslyn Analyzers task, review the Roslyn-based analyzers.

You can find the analyzer package installed and used by this build task on the NuGet page Microsoft.CodeAnalysis.FxCopAnalyzers.

For information about YAML configuration for this task, check our Roslyn Analyzers YAML options

TSLint task

For More information about TSLint, go to the TSLint GitHub repo.

Note

As you might be aware, the TSLint GitHub repo home page says that TSLint will be deprecated sometime in 2019. Microsoft is investigating ESLint as an alternative task.

For information about YAML configuration for this task, check our TSLint YAML options

Publish Security Analysis Logs task

Details of task configuration are shown in the following screenshot and list.

• Artifact Name: Any string identifier.
• Artifact Type: Depending on your selection, you can publish logs to your Azure DevOps Server or to a shared file that is accessible to the build agent.
• Tools: You can choose to preserve logs for specific tools, or you can select All Tools to preserve all logs.

For information about YAML configuration for this task, check our Publish Security Logs YAML options

Security Report task

Details of Security Report configuration are shown in the following screenshot and list.

• Reports: Select any of the Pipeline Console, TSV File, and Html File formats. One report file is created for each selected format.
• Tools: Select the tools in your build definition for which you want a summary of detected issues. For each tool selected, there might be an option to select whether you see errors only or see both errors and warnings in the summary report.
• Advanced Options: If there are no logs for one of the tools selected, you can choose to log a warning or an error. If you log an error, the task fails.
• Base Logs Folder: You can customize the base logs folder where logs are to be found. But this option is typically not used.

For information about YAML configuration for this task, check our Security report YAML options

Post-Analysis task

Details of task configuration are shown in the following screenshot and list.

• Tools: Select the tools in your build definition for which you want to conditionally inject a build break. For each tool selected, there might be an option to select whether you want to break on errors only or on both errors and warnings.
• Report: You can optionally write the results that are causing the build break. The results are written to the Azure DevOps console window and log file.
• Advanced Options: If there are no logs for one of the tools selected, you can choose to log a warning or an error. If you log an error, the task fails.

For information about YAML configuration for this task, check our Post Analysis YAML options

Next steps

For information about YAML based configuration, refer to our YAML Configuration guide.

If you have further questions about the Security Code Analysis extension and the tools offered, check out our FAQ page.