How to find rule category for external .NET analyzer (Microsoft.CodeAnalysis.NetAnalyzers)

SonarQube Server / Community Build
1

Version: SonarQube 8.9.5, Azure DevOps Server 2020.1.1 using SonarQube build tasks

What am I trying to achieve: After enabling rule CA3147 in the Roslyn scanner, and seeing the results show up in SonarQube, I’d like to classify those issues as Vulnerability instead of Code Smell.

What have I tried so far:

  • Added the Microsoft.CodeAnalysis.NetAnalyzers NuGet package to my project
  • Configured the .ruleset and .editorconfig files to include CA3147 as a warning
  • Confirmed that the compiler finds associated issues
  • Confirmed that those issues show up in SonarQube after a build & code analysis
  • Reviewed Importing Third-Party Issues | SonarQube Docs (.NET section at the bottom)
  • Reviewed CA3147: Mark verb handlers with ValidateAntiForgeryToken (code analysis) - .NET | Microsoft Docs, where the rule category is listed as “Security”
  • Added sonar.cs.roslyn.vulnerabilityCategories=Microsoft.CodeAnalysis.NetAnalyzers.Security,Security to the code analysis configuration
  • Added “Microsoft.CodeAnalysis.NetAnalyzers.Security” and “Security” in the “Rule categories associated with Vulnerabilities” section in Administration - External Analyzers in SonarQube
  • Reviewed various articles on Google, but I seem to be either the first person to try this or I’m missing something really obvious.

The issues still show up as Code Smell. I have a feeling that the category identifier used by SonarQube is something other than “Microsoft.CodeAnalysis.NetAnalyzers.Security” or just “Security”. Where can I find this category? Neither the build log nor the code analysis log seem to include it. In Visual Studio, the category is just listed as “Security”.

In the issues itself, when I click on “Why is this an issue?”, I see roslyn:CA3147 as a rule identifier in the top right corner. As a future improvement, could you add the category identifier there?

Edit: Here’s an excerpt from the issues.json that Roslyn creates during the analysis, and that is then processed by SonarQube. The category is set as “Security” there:

        "CA3147": {
          "id": "CA3147",
          "shortDescription": "Mark Verb Handlers With Validate Antiforgery Token",
          "defaultLevel": "warning",
          "helpUri": "https://docs.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca3147",
          "properties": {
            "category": "Security",
            "isEnabledByDefault": true,
            "tags": [
              "Telemetry",
              "EnabledRuleInAggressiveMode"
            ]
          }
        },
2

Update: After reviewing the code responsible for classifying the external issues at Import third party Roslyn issues (fix #1825) (#1850) · SonarSource/sonar-dotnet@c1ad3b2 · GitHub I know what’s going on. If SonarQube already knows about an issue, the classification step is skipped, which means that external issues cannot be reclassified once SonarQube knows about them. This is a per-branch issue; analyzing the same code in a new branch will apply the correct classifications to the issues.

To fix this for an existing branch, if you don’t want to reclassify issues manually:

  • Make the required category changes, either in the global SonarQube administration or in the code analysis configuration
  • Run one code analysis with sonar.cs.roslyn.ignoreIssues=true in the code analysis configuration
  • Delete the previous, erroneously classified analysis from SonarQube
  • Remove the sonar.cs.roslyn.ignoreIssues=true configuration and run another analysis. All issues should now be classified correctly.

For reference: The category given in the Microsoft documentation is all that’s needed in the end, e.g. Security, Reliability, etc.

Leaving this here for others who may have the same issue.

3

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.