Microsoft Security Code Analysis

The Microsoft Security Code Analysis Extension is a collection of tasks for the Azure DevOps Services platform. These tasks automatically download and run secure development tools in the build pipeline. The extension is now in a Private Preview (by invitation)

Sign Up

Run security analysis tools in Azure DevOps Pipelines

The Secure Development Lifecycle (SDL) Guidelines recommend that teams perform static analysis during the implementation phase of their development cycle.
The Microsoft Security Code Analysis extension empowers you to do so, easily integrating the running of static analysis tools in your Azure DevOps pipelines.

Simple Configuration and Execution

Adding security static analysis tools to your build is as simple as adding new build tasks. Just provide a few parameters, or go with the defaults. The tasks run as part of your DevOps pipeline and produce logs with results of any findings.

Keep Your Builds Clean

Once you have addressed the issues reported by the tool, you can configure the extension to introduce a build break should any new issues being introduced and detected by the tools, for example, in a continuous integration build, which can run on every pull request.

Auto-Update

The Azure DevOps build tasks and tools can be set to stay up-to-date (and are by default). If there is an updated version of the tool, there is no need to download and install it; this extension takes care of that for you.

Under the Hood

The Microsoft Security Code Analysis Extension build tasks abstract the complexities of:
   1.  Running security static analysis tools, and
   2.  Processing the results from log files to create a summary report or break the build.

Each build task will:

1. Prompt the user for a minimal list of options related to the source and binaries that are to be scanned. The task will provide defaults where possible.
2. Download the latest (or selected) version of the tool from a restricted nuget feed to the build agent.
3. Sanitize and convert user input into (often complex) command-line arguments, and then launch the tool on the build agent.
4. Save tool output log files locally on the build agent.

You will also want to add up to three helpful post-processing tasks after all other tool tasks complete, to produce a summary report of the issues found by the tools you run and to preserve tool log files to the Azure DevOps Server or to a file share. And perhaps most importantly, understand that when a security tool finds an issue the build does NOT break or fail. Should you wish to inject a build break (a build task failure) based on security findings by one of the tools, you will need ot add the Post-Analysis build task.
See Post-Processing build tasks below for more details on these three tasks.

Security Static Analysis Tools

The Microsoft Security Code Analysis extension makes readily available to you, the latest versions of important static analysis tools. The extension includes both Microsoft Internal and Open Source tools. The tools get automatically downloaded on the cloud-hosted agent once you configure & run the pipeline using the corresponding build task. Below is the list of tools that are available in the extension today.
Stay tuned for more, and send us your suggestions for tools that could be added.

Credential Scanner

Passwords and other secrets stored in source code is currently a big problem. Credential Scanner is a static analysis tool that detects credentials, secrets, certificates, and other sensitive content in your source code and your build output.



BinSkim

BinSkim is a Portable Executable (PE) light-weight scanner that validates compiler/linker settings and other security-relevant binary characteristics. The build task provides a command line wrapper around the BinSkim.exe application. BinSkim is an open source tool.



TSLint

TSLint is an extensible static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors. It is widely supported across modern editors and build systems and can be customized with your own lint rules, configurations, and formatters. TSLint is an open source tool.



Roslyn Analyzers

Microsoft's compiler-integrated static analysis tool for analyzing managed code (C# and VB).



Microsoft Security Risk Detection

Security Risk Detection is Microsoft's unique cloud-based fuzz testing service for identifying exploitable security bugs in software.



Anti-Malware Scanner

The Anti-Malware Scanner build task is now included in the Microsoft Security Code Analysis Extension. It must be run on a build agent which has Windows Defender already installed.

Analysis and Post-Processing of Results


The Microsoft Security Code Analysis extension has three build tasks to help you process and analyze the results found by the security tools tasks.

  • The Publish Security Analysis Logs build task preserves logs files from the build for investgiation and follow-up.
  • The Security Report build task collects all issues reported by all tools and adds them to a single summary report file.
  • The Post-Analysis build task allows customers to inject build breaks and fail the build should an anlysis tool report security issues found in the code that was scanned.

Publish Security Analysis Logs

The Publish Security Analysis Logs build task preserves the log files of the security tools run during the build.
They can be published to the Azure DevOps Server artifacts (as a zip file), or copies to an accessible file share from your private build agent.


Security Report

The Security Report build task parses the log files created by the security tools run during the build and creates a summary report file with all issues found by the analysis tools.
The task can be configured to report findings for specific tools or for all tools, and you can also choose what level of issues (errors or errors and warnings) should be reported.


Post-Analysis (Build Break)

The Post-analysis build task enables the customer to inject a build break and fail the build in case one ore more analysis tools reports findings or issues in the code.
Individual build tasks will succeed, by design, as long as the tool completes successfully, whether there are findings or not. This is so that the build can run to completion allowing all tools to run.
To fail the build based on security issues found by one of the tools run in the build, then you can add and configure this build task.
The task can be configured to break the build for issues found by specific tools or for all tools, and also based on the severity of issues found (errors or errors and warnings).

Start Using the Microsoft Security Code Analysis Extension

The extension makes the latest versions of important static analysis tools readily available.

1. Navigate to your Azure DevOps Organization page (e.g. http://dev.azure.com/contoso)
2. Click on the shopping bag icon in the upper right corner next to your name, then click Manage extensions
3. If you do not see the Microsoft Security Code Analysis Extension listed under the Installed or Shared with this account sections, please follow the How do I get the Microsoft Security Code Analysis Extension shared with my account? section below
4. Click the Microsoft Security Code Analysis extension
5. On the subsequent page, Click Get it free
6. Choose the Azure DevOps Organization to install the extension on from the dropdown
7. Click Install. Once it completes, you can Proceed to the account

Microsoft Security Code Analysis tasks work like any other Azure DevOps Build task. Here's how:

1. Edit your DevOps pipeline
2. Click Add Task
3. Click All or Utility under Add Tasks
4. Find the secure development tool you would like to run (our tasks have a green security shield icon) and click Add on the right hand side
5. Use the 'Basic' input type to have the command line generated for you. Accept the defaults or modify them (some tools require input that does not have a default). Or,
6. Use the 'Command-Line' input type, and specify exact command-line arguments, if you are familiar with the tool and its command-line parameters.
Note that file or directory paths are relative to the root of your source repository, and parameters specifying the output folder/files will be replaced with the common location that we have defined on the build agent.
7. Queue a new build.

Tips

To run analysis after your build, place the Microsoft Security Code Analysis build tasks after the Publish Build Artifacts step of your build. That way, your build can finish and post results before running static analysis tools.

Always check the 'Continue on Error' option of secure development build tasks. Even if 1 tool fails, the others can run; there are no interdependencies.

Microsoft Security Code Analysis build tasks will fail ONLY if the tool fails to run successfully, but they will NOT fail if and when the tool identifies issues in the code. You can configure your build to break when a tool identifies issues in the code, using the 'Post-Analysis' build task.

Some Azure DevOps build tasks are NOT supported when run via a “Release” Pipeline. This is a limitation of Azure DevOps; they do not support tasks that publish artifacts from within a Release pipeline.

The results log files produced by Microsoft Security Code Analysis tasks and tools can be saved by publishing them as a post-build artifact within Azure DevOps, or to a specified file server with a path to the file share. Publishing artifacts to the server or to a file share can be accomplished using the Publish Security Analysis Logs build task, which is included in the Microsoft Security Code Analysis extension (another green shield build task).

Once a build has completed, you can download the build artifacts and view the tool log files. You can also use the Create Security Analysis Report build task for viewing analysis result logs for specified tools, including the ability to create an actionable HTML report file. See screenshot below for the options available in this task:

FAQs

Got questions? Check out below for more information. Still don't see it? No problem, just ask us at Microsoft Security Code Analysis Support

Click here for more details on Azure DevOps Services.

1. Navigate to your Azure DevOps Organization page (e.g. http://dev.azure.com/contoso)
2. Click on the shopping bag icon in the upper right corner next to your name, then click Manage extensions
3. If you do not see the Microsoft Security Code Analysis Extension listed under the Installed or Shared with this account sections, please follow the How do I get the Microsoft Security Code Analysis Azure DevOps Extension shared with my account? section below
4. Click the Microsoft Security Code Analysis extension
5. On the subsequent page, Click Get it free
6. Choose the Azure DevOps Organization to install the exension from the dropdown
7. Click Install. Once it completes, you can Proceed to account

The extension will be shared with your Azure DevOps Organization once you have been approved to join the private preview.

The following criteria are required for integration

1. An Azure DevOps Organization
2. Permissions to install extensions to the Azure DevOps Organization
If you do not have access, continue with the install steps and you will be able to request access from your account administrator
3. Source code that can be synced to a cloud-hosted Azure DevOps pipeline

Once the extension is installed, the secure development build tasks will be visible and available to add to your DevOps pipelines

No, the extension is not available for download and install for TFS.

Microsoft Security Code Analysis build tasks work like any other Azure DevOps Build tasks. Here's how:

1. Edit your DevOps pipeline
2. Click Add Task
3. Click All or Utility under Add Tasks
4. Find the secure development tool you would like to run (tasks with a green security shield icon) and click Add on the right hand side
5. Use the 'Basic' input type to have the command line generated for you. Accept the defaults or modify them (some tools require input that does not have a default). Or,
6. Use the 'Command-Line' input type, and specify exact command-line arguments, if you are familiar with the tool and its command-line parameters.
Note that file or directory paths are relative to the root of your source repository, and parameters specifying the output folder/files will be replaced with the common location that we have defined on the build agent.
7. Queue a new build.

Tips

To run analysis after your build, place the Microsoft Security Code Analysis build tasks after the Publish Build Artifacts step of your build. That way, your build can finish and post results before running static analysis tools.

Always check the 'Continue on Error' option of secure development build tasks. Even if 1 tool fails, the others can run; there are no interdependencies.

Microsoft Security Code Analysis build tasks will fail ONLY if the tool fails to run successfully, but they will NOT fail if and when the tool identifies issues in the code. You can configure your build to break when a tool identifies issues in the code, using the 'Post-Analysis' build task.

Some Azure DevOps build tasks are NOT supported when run via a “Release” Pipeline. This is a limitation of Azure DevOps; they do not support tasks that publish artifacts from within a Release pipeline.

Yes and no. Depending on the type of analysis tool, the source code itself may be the only thing required or the output of the build may be required. For example, since CredScan analyzes files within the code repository folder structure, you could run the CredScan and Publish Security Analysis logs build tasks in a standalone build to retrieve results.

For other tools that analyze post build artifacts, like BinSkim, the build will be required first.

No. At this time we only support scanning files from within an Azure DevOps build

Yes, you can introduce a build break when any tool reports an issue, a finding, in its log file. Just add the Post-Analysis build task and check the checkbox for any tool for which you would like to break the build. You can choose to break the build when a tool reports errors, or warnings and errors, in the UI of the Post-Analysis task.

For the most part, the Azure DevOps build tasks are direct wrappers around the command line arguments of the security tools. Anything you would normally pass to the tool on the command line from your desktop, you can pass to the Arguments input of the build task.

Here is a list of noticeable differences:

1. The tool will be executing from the source folder of the agent $(Build.SourcesDirectory) or %BUILD_SOURCESDIRECTORY%. Example: C:\agent\_work\1\s
2. Paths in the Arguments can be relative to the root of the source directory listed above or absolute either by running an on-prem agent with known deployment locations of local resources or using Azure DevOps Build Variables
3. Tools will automatically provide an output file path or folder if an output path is provided, it will be removed and replaced with a path to our well-known logs location on the build agent
4. Some additional command line parameters are sanitized and removed on some tools, such as the addition or removal of options to ensure that no GUI is launched.

No, running the secure development tools against multiple repositories in a single pipeline is currently not supported.

The build tasks currently sanitize user input and update the location of the output file generated to a common location on the build agent. Please see the following question for more information on this location.

The build tasks automatically add output paths to the following well-known location on the build agent $(Agent.BuildDirectory)\_sdt\logs. By standardizing on this location, we can guarantee that other teams producing code analysis logs or consuming them will have access.

Yes, all tasks and tools in the extension can be executed on a hosted build agent.
Note that the Anti-Malware build task requires a build agent with Windows Defender enabled, which is true on "Hosted VS2017" build agents. (It will not run on the legacy/VS2015 "Hosted" agent.)
Signatures cannot be updated on these agents, but the signature should always be relatively current, less than 3 hours old.

In most cases, Yes.

However, tasks that publish artifacts are not supported by Azure DevOps to be run from within Release Pipelines: "The only category of tasks not expected to work with Release are the ones that publish artifacts. This is because, as of now, we don’t have support for publishing artifacts within Release".

This prevents the "Publish Security Analysis Logs" task from running successfully from a release pipeline; it will fail, with a descriptive error message.

The build tasks a) download NuGet packages for the tools from the following Azure DevOps Package Management feed: https://securitytools.pkgs.visualstudio.com/_packaging/SecureDevelopmentTools/nuget/v3/index.json
or using the Node Package Manager, which must be pre-installed on the build agent (example: "npm install tslint").

Upon installing, the security build tasks provided by the extension will become available for use by all users in your organization. When creating or editing a DevOps pipeline, these tasks will be available to add from the build task collection list. Otherwise, installing the extension in your Azure DevOps organization has no impact. It does not modify any account or project settings or pipelines.

No. Installing the extension will make the security build tasks available to add to your DevOps Pipelines. Users are still required to add or update build definitons to integrate the tools into your build process.