Ignoring Sonar Findings#

In rare cases, Sonar might report a finding that you cannot fix immediately or that reviewers agree to accept. Please only choose this approach as a last resort.

Remember that Sonar often displays findings originating from another tool. That means a single issue can have both a Sonar identifier and a tool-specific identifier. For example, security findings reported by bandit can usually be referred to by their Bandit rule code as well.

Example#

For subprocess.run(args), Sonar could for example report subprocess call - check for execution of untrusted input. In the Sonar UI, when clicking on “Why is this an issue?”, you will find references like

  • B603: Test for use of subprocess with shell equals true external_bandit:B603

  • See description of Bandit rule B603 at the Bandit website.

In this case, the Bandit error code is B603. When possible, prefer handling the finding at the source-tool level so that the reason is documented in code.

Ignoring a Finding Via a Source Code Comment#

If the originating tool supports it, the recommended way of ignoring a finding is to add an explicit source code comment on the affected line:

subprocess.run(args)  # nosec: B603 - risk of untrusted input is accepted

The keyword nosec is defined by Bandit in this case.

Alternatively, you could also accept a finding in the Sonar UI:

Accepting a Finding Via Sonar UI