Microsoft Security Code Analysis – a tool that seamlessly empowers customers to enable security controls in your CI/CD pipeline

Developer Support

In this post, Sr App Dev Managers Rob Smith and Syed Mehdi talks about Microsoft Security Code Analysis – a tool that seamlessly empowers customers to enable security controls in their CI/CD pipeline.

March 2021 Update – MSCA will be retired March 1, 2022.

The MSCA team is committed to bringing Secure Development Lifecycle (SDL) practices to our customers and is constantly prioritizing its development efforts to ensure the delivery of great tools, value, and user experience. As the team continues their prioritization effort and allocate more resources to support some of Microsoft’s key bets in the security space, unfortunately effective March 1, 2022, the MSCA extension will be retired.

Over the next year, there will be no additional upgrades or planned enhancements for the MSCA extension; however, the extension will continue to be supported until March 1, 2022 and existing customers will continue to benefit from its capabilities.

Please refer to GitHub Advanced Security and OWASP Source Code Analysis Tools for alternative options.

In Microsoft Developer Support, as we help customers modernize their development practices, one of the areas that we focus on is how to adopt application security practices to reduce security risk while minimizing impact to agility. Back in May, we talked about Microsoft Security Risk Detection, and now in this post, we want to introduce you to a tool, really a toolset, released this summer, that you can use to integrate security controls into your development process: Microsoft Security Code Analysis. We have found application security practices and tools integration to be critical for customers to successfully and continuously release a modern, cloud ready application.

We believe that Secure DevOps (or DevSecOps, whichever name works for you) encompasses both a set of practices and a mindset shift to help customer adopt security principles and practices aligned with the culture shift and integrated with the practices, of DevOps. Secure DevOps practices include and build on those practices that are part of the Microsoft Security Development Lifecycle (SDL).

During our Secure DevOps Workshop, which we offer in Developer Support, we talk about the key principles for Secure DevOps. Two of these principles are Shift Left and Automate and Secure and Compliant Pipeline. Shift Left and Automate is about bringing security testing and controls into the development process instead of just scanning code and deployed application late in the development or even release cycle. Secure and Compliant Pipeline addresses the risk and challenges of building and deploying software in a CI/CD pipeline. And, there are Secure DevOps practices that align with these principles, specifically Use Tools and Automation and Keep Credentials Safe.

Microsoft Security Code Analysis (MSCA) enables you to integrate these principles and practices into your CI/CD pipeline when using Azure DevOps (Services only, not available currently in Server).

Use Tools and Automation

MSCA provides a toolset that includes both Static Application Security Testing (SAST) including Credential Scanner and Roslyn Analyzers and Dynamic Application Security Testing (DAST), specifically integration with Microsoft Security Risk Detection Fuzzing. It makes it easy to run these automatically as part of your build and release pipelines in Azure DevOps. This empowers you to catch and remediate security issues early and often in your development cycle (Shift Left) utilizing automation since neither developers nor IT security need to manually run the tools on every pull request or delivery to test.

These are some of the same tools that Microsoft engineers are using internally to scan their code and binaries for security vulnerabilities.

Azure DevOps Build pipeline shown configured with various MSCA tasks including Credential Scanner and Roslyn Analyzers. The Task configuration panel shows the Roslyn static code analyzer configured to run SDL rulesets against the code during a build

Keep Credentials Safe

It is vital that you ensure that credentials are not stored in source code or configuration (or other) files, whether it be in source control or shipped through different environments. This reduces the risk that secrets can inadvertently be exposed to people who should not have access to them, which could lead to your application and data being vulnerable. It is no longer enough to just assume that file system security or a firewall will ensure that someone hasn’t already accessed your code and config files, or that someone hasn’t inadvertently shared those, such as via email or file sharing site.

MSCA provides Microsoft’s proprietary tool called Credential Scanner to help you ensure that your DevOps team(s) follow this best practice. Credential Scanner includes 25 searchers supporting 70+ file types out of the box along with custom patterns if you have additional needs.

Security Simplified

The security tools are provided as tasks that you can easily add and configure in your Azure DevOps pipelines. You use the Azure DevOps Pipeline Task UI instead of worrying about the complexities of running each tool. Default settings make it simple to add and run one or more of the tools whenever your pipeline is executed during a build or release. And, logs are generated that provide a summary and detail the findings in 1 report. In addition, you can also set up the SCA tasks in your pipeline using YAML, which enables you to reuse your pipeline definition and store it in your repository as code.

Credential Scanner and Roslyn Analyzers tasks shown running as part of the build pipeline

Clean Builds

You can use the tools to address issues with your code to get started, and then you can configure your build to break whenever new security problems are introduced in the code. This allows you to block Pull Request completion to notify developers of an issue early on. Your developers can then add work items to the backlog to address as a priority, preventing any issue from creeping into code and eventually being deployed, thus reducing risk.

Build failed due to security issues found

Set It and Forget It

The build tasks and tools are automatically updated, by default, so you don’t need to manage keeping anything up to date.

The Security Code Analysis Toolset

  • Anti-Malware Scanner: Anti-Malware Scanner is run on a build agent that has Windows Defender already installed.
  • Binskim: An open-source tool Portable Executable (PE) light-weight scanner that validates compiler/linker settings and other security-relevant binary characteristics.
  • Credential Scanner: A proprietary static analysis tool that detects credentials, secrets, certificates, and other sensitive content in your source code and your build output.
  • Microsoft Security Risk Detection: Security Risk Detection is Microsoft’s unique cloud-based fuzz testing service for identifying exploitable security bugs in software. This service requires a separate onboarding process.
  • Roslyn Analyzers: Microsoft’s compiler-integrated static analysis tool for analyzing managed code (C# and VB).
  • TSLint: An open source extensible static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors. and can be customized with your own lint rules, configurations, and formatters.

You can review issues found right in the console output and logs

Start using MSCA with Azure DevOps

Microsoft Security Code Analysis is available as a subscription under Premier and Unified Support. Please contact your Technical Account Manager or Application Development Manager for information on the subscription including how to get this enabled for your Azure DevOps Org as part of a 2-week free trial. Documentation is available publicly here.

1 comment

Discussion is closed. Login to edit/delete existing comments.

  • Rob Smith (ADM)Microsoft employee 0

    To answer a frequently asked question, the SCA tasks are only available for Azure DevOps Services currently and cannot be run in Azure DevOps Server 2019 on premises. There is an FAQ in our public facing documentation about this here. Your application though can be deployed anywhere.

Feedback usabilla icon