Consider releasing Roslyn Analyzers and Fixers

Roslyn analyzers and fixers work as part of the compiler and can be used in any IDE or tooling the supports Roslyn analyzers.

The Roslyn compilers can output diagnostics in SARIF formant (-errorLog) that can be used by other tooling.

[scovetta]

@paulomorgado Just to add a little to this – static analyzers make tradeoffs in different areas – the advantage of Roslyn analyzers are execution speed, disadvantages (IMHO) are complexity of rule creation and the languages that can be analyzed. CodeQL isn’t usually as performant, but enables for a much deeper analysis, and still a relatively high cost of rule creation.

DevSkim goes at it from the other direction – rules are very easy to write and are language agnostic. This means that yes, it’s easy to “trick” DevSkim into not finding an issue, and there can be more false positives.

There’s no “best” tool for all jobs – we think that DevSkim has a useful spot in the mix, similar to Semgrep, but we don’t want to try to make DevSkim something that it isn’t.

If your original comment was about creating new Roslyn rules to detect more security bugs, that would always be helpful, but it isn’t something that we (the folks managing DevSkim) are actively working on. You might want to consider security-code-scan (NuGet) in case they’ve already implemented what you’re looking for.

[paulomorgado]

Thanks.