The Microsoft Security Risk Detection Service has been discontinued

A build task for Security Risk Detection is now included in the Microsoft Security Code Analysis Extension. This page has the steps needed to configure & run the build task as part of your build pipeline. Click here for information on the Security Risk Detection service.


1. You are using Azure DevOps Services.
2. The Microsoft Security Code Analysis Extension is installed in your account.
3. You have created and configured an account with the Risk Detection service. This service requires a separate onboarding process; it is not 'plug-and-play' as most of the other tasks in this extension. Please refer to Microsoft Security Risk Detection and Microsoft Security Risk Detection: How To for instructions.


1. Open your team project from your Azure DevOps Account.
2. Navigate to the Build tab under Build and Release
3. Select the Build Definition into which you wish to add the Risk Detection build task.
  • New - Click New and follow the steps detailed to create a new Build Definition.
  • Edit - Select the Build Definition. On the subsequent page, click Edit to begin editing the Build Definition.
4. Click + to navigate to the Add Tasks pane.
5. Find the Risk Detection build task either from the list or using the search box and then click Add.

Customizing the Risk Detection Build Task:

1. Click the newly added task to see the different options available.

2. Enter the required data; each option has hovertext help.
  • Azure DevOps Service Endpoint Name for MSRD: If you have created a Generic type of Azure DevOps Service Endpoint to store the MSRD instance URL (you have onboarded to) and the REST API access token, then you can choose that service endpoint. If not, click the Manage link to create and configure a new service endpoint for this MSRD task.
  • Account ID: It is a GUID that can be retrieved from the MSRD account URL.
  • URLs to Binaries: A semicolon delimited list of publicly available URLs (to be used by the fuzzing machine to download the binaries).
  • URLs of the Seed Files: A semicolon delimited list of publicly available URLs (to be used by the fuzzing machine to download the seeds). This field is optional if the seed files are downloaded together with the binaries.
  • OS Platform Type: The OS platform type (Windows, or Linux) of machines to run the fuzzing job on.
  • Windows Edition / Linux Edition: The OS edition of machines to run the fuzzing job on. You can overwrite the default value if your machines have a different OS edition.
  • Package Installation Script: Provide your script to be run on a test machine to install the test target program and its dependencies before submission of the fuzzing job.
  • Job Submission Parameters:
    • Seed Directory: Path to the directory on the fuzzing machine containing the seeds.
    • Seed Extension: The file extension of the seeds
    • Test Driver Executable: Path to the target executable on the fuzzing machine.
    • Test Driver Executable Architecture: The target executable file architecture (x86 or amd64).
    • Test Driver Arguments: The command-line arguments passed to the test target executable. Note that the "%testfile%" symbol, including the double quotes, will be automatically be replaced with the full path to the target file the test driver is expected to parse, and is required.
    • Test Driver Process Exits Upon Test Completion: Check if the test driver terminates itself upon completion; Uncheck if the test driver needs to be forcibly closed.
    • Maximum Duration (in seconds): Provide an estimation of the longest reasonably-expected time required for the target program to parse an input file. The more accurate this estimation, the more efficient the fuzzing run.
    • Test Driver Can Be Run Repeatedly: Check if the test driver can be run repeatedly without depending on a persisted/shared global state.
    • Test Driver Can Be Renamed: Check if the test driver executable can be renamed and can still work correctly.
    • The Fuzzing Application Runs as a Single OS Process: Check if the test driver runs under a single OS process; Uncheck if the test driver spawns additional processes.