Start with the analyzers already in the .NET SDK. For projects targeting .NET 5 or later they are on by default, but only a small set runs as warnings. Raise AnalysisMode to Recommended or All, pin AnalysisLevel so upgrades do not surprise you, and turn the warnings you care about into build errors.
What is already there
Microsoft's code analysis overview says the Roslyn analyzers ship with the SDK and need no separate install. Rules appear with a CA prefix for code quality, including security, performance and reliability, and an IDE prefix for style. By default, only a small number of rules are enabled as build warnings.
The AnalysisMode ladder
| Value | Effect |
|---|---|
| None | All rules disabled, opt in individually |
| Default | A small set as warnings, some as editor suggestions |
| Minimum | Highly recommended rules become build warnings |
| Recommended | More rules as build warnings |
| All | All rules as build warnings, with a few legacy exceptions |
There are also category specific versions, such as AnalysisModeSecurity, so you can be stricter for security than for everything else. Check the MSBuild properties reference for the exact names.
<PropertyGroup>
<AnalysisLevel>latest-Recommended</AnalysisLevel>
<AnalysisModeSecurity>All</AnalysisModeSecurity>
</PropertyGroup>
Control the surprises
By default AnalysisLevel is latest, so new SDKs bring new rules. Setting it to a version, such as 8.0, locks the set so an SDK upgrade does not add warnings overnight. You still get bug fixes. Alternatively, the Microsoft.CodeAnalysis.NetAnalyzers package decouples rule updates from SDK updates.
Make findings block
- Enable a stricter mode in a branch.
- Count the warnings by rule and by project.
- Fix quick wins, and suppress with an editorconfig entry only with a written reason.
- Promote the security rules you trust to errors, using a dotnet_diagnostic severity line per rule.
- Build with warnings as errors in CI. If you do not want every CA warning to break the build, set CodeAnalysisTreatWarningsAsErrors to false and choose rules deliberately.
[*.cs]
dotnet_diagnostic.CAxxxx.severity = error
Replace CAxxxx with the ID of a security rule from Microsoft's code quality rule list that matches your code.
Limits to remember
Analyzers find patterns in your source. They do not tell you whether a dependency has a known vulnerability, and they do not follow data across services. Treat them as one layer next to dependency audit and testing.
Analyzers are also dependencies
Third party analyzers arrive as NuGet packages and run inside your compiler. Review them like any package, as covered in can a NuGet package run code during your build.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how a static finding is reported with what an analyzer warning gives you in the build log.
Safeguard offers code scanning alongside dependency scanning, and a free scan is the quickest way to try it.
Quick check
Do I need to install a package to get .NET analyzers?
Not for projects targeting .NET 5 or later. They ship with the SDK. Older targets need EnableNETAnalyzers set to true.
Will upgrading the SDK add new analyzer warnings?
By default yes, because AnalysisLevel is latest. Set it to a version to lock the rule set.
Sources
Last reviewed: 19 October 2026.
