Rule Suppression Format

[ejohn20]

@joshbw proposed a standard format for suppressing false positives using commands on a line of code in our extension tools.

Fields proposed:

• ToolName
• Identifier (SEC###, DS###)
• Comment
• Expiration Date
• Hash code
• Author

What other fields would be helpful?

Format could be something simple:

• //ToolName:Identifier:HashCode:Author:Comment:EndDate

Thoughts on the format?

[skosten]

Really like this idea. However, would give the tool the option of exposing those, e.g., where developer silences issue but isn't really fixed. Would like security auditor to be able to see if needed. Steve Kosten Make a Loan, Make a Difference: Kiva.org

…

On Sun, Sep 10, 2017 at 11:54 PM, Eric Johnson ***@***.***> wrote: @joshbw <https://github.com/joshbw> proposed a standard format for suppressing false positives using commands on a line of code in our extension tools. Fields proposed: - ToolName - Identifier (SEC###, DS###) - Comment - Expiration Date - Hash code What other fields would be helpful? Format could be something simple: - //ToolName:Identifier:HashCode:Comment:EndDate Thoughts on the format? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#34>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIAEI55USi3uJWaXMwfAj5vBRAjsA_cTks5shMsfgaJpZM4PSqvi> .

[ejohn20]

Agree - on our side we can easily add a configuration option to ignore suppression if desired.

Also, I think we should track who is suppressing what. I added an Author tag above, which could be the login id of the person that triggers the suppression.

[felickz]

Are you looking to address an issue that the native suppression mechanisms do not support? (compiler pragma directives and Suppress Message attributes)

The existing GlobalSuppressions file seems to be the best place to store false positives as we can then put a watch on the suppression file and audit any changes made there.

Style Analyzers "CodeAnalysisSuppressionMustHaveJustification" rule seems to help enforce some level of documentation: SA1404

[ejohn20]

@felickz this is mainly for the non-code file analyzers, which the built in suppression does not support. The standard code warnings work just fine using the built in suppression.

[ejohn20]

Next release will include a .pumafile that allows suppression of findings (code and non-code).

[brettpostin]

I've just come across this issue as I was looking for a way to prevent developers easily suppressing rules without oversight. This sounds like a timely addition!

Are you able to give any timescales for the next release?

[ejohn20]

@brettpostin We just released this feature in our professional edition last week. We will iron the documentation out for this over the next few weeks. It is something that will be contributed back to the open source edition in time, but likely not until Q2 2019.