While looking analysis results, you could find that (for example) a Kiuwan rule is generally helpful and must be kept active. But, in some concrete cases, it is not applicable (or it is not properly working) and some defects should not be considered in the analysis.
Reasons to “silence” (or mute) those defects can be of very different nature but you might decide that, the rule should not be applied in certain particular cases o situations.
In any case, you want to keep active the rule but discard some specific defects. Kiuwan provides the Mute Defect functionality to do it.
Please, also have a look at How to manage Kiuwan defects when I do not completely agree with them
Defects muting can be applied to different scopes:
Kiuwan allows you to declare mute patterns for all the above situations, letting you to suite Kiuwan muting mechanism to your specific needs.
What is important to remember is that muted defects will not be considered when passing an Audit or calculating any Indicator.
Muted defects are still there (you can inspect them) but will not be part of the calculations made by Kiuwan.
Probably, you might be wondering at this moment some questions:
Kiuwan allows you to mute defects at any moment of your applications life cycle.
If you are using Kiuwan Life Cycle, most probably you will have application baselines (performed periodically at quite defined promotion to production stages) and deliveries (at nightly-build or quite often while continuous development).
In previous releases, Kiuwan only allowed you to mute defects in baseline analyses. Now, you can also mute defects found during a delivery analysis.
IMPORTANT: you can only mute defects in a delivery executed over the last available baseline. Once muted, those muted defects will be considered in further delivery and baseline analyses |
After an analysis, you will need to spend some time looking carefully to the defects found during the analysis, to fully understand them before to consider submit its correction to developers. During that review, some of them will be reviewed very fast but other may take a while.
Kiuwan can help you to mark the “Review Status” for any specific defect.
This way, as you review the defects you can mark them as “To review” or “Reviewed” (or leaving blank, of course) for review tracking purposes.
Kiuwan lets you manage muting in several pages:
Let’s go through them.
Once you select the last analysis of an application (either in Code Security or in code Analysis), go to Defects or Vulnerabilities tab.
For explanation purposes, in our explanation we will refer to both as “Defects” tab. In case of any difference, we will note it.
We refer to “last” analysis, because you can only mute on the last analysis. The mute pattern applies to the current and further analyses .. (past analyses cannot be changed)
At the different scopes (rule, file, defect, etc), you can open the left menu and you can select the Mute option.
In our example, we will mute the 4 defects of XSS rule on the selected JSP. So, clicking on the jsp will open the following dialog:
When you mute something, you are creating a so-called Mute Pattern. Remember that a mute pattern can apply to a unique defect or to a set of defects, that’s the reason of that nomenclature.
Besides descriptive data of the mute pattern (such as the involved rule, file ,etc), you can add the reason (or explanation) that justifies the mute pattern.
You can select between common reasons to mute defects (it’s a false positive, the defects are on generated code and cannot be changed, etc.), but you can also add your own.
Just in case you select to mute a rule with defects in more than one file, the dialog will be as in the figure
In this case, you will be able to specify as many file patterns as you want. In this case, the mute pattern will be applied to all the files that match any of the indicated patterns.
Please, remember that a file pattern must be indicated following ANT pattern syntax. For further help on ANT patterns syntax visit https://ant.apache.org/manual/dirtasks.html
After applied, muted defects will appear shadowed and with an icon.
You will also see a message (in yellow) indicating that there are muted defects but Indicators have not been recalculated yet.
If you need to add mode mute defect patterns ignore that message, otherwise click on Recalculate so the indicators are recalculated taking into account muted defects.
As an alternative to the above page, you can also mute defects opening the Mute Defect submenu in Defects tab.
This page can be used alone or together with the previous page.
In case you have already defined mute patterns, Muted Patterns panel shows all defined so far. You can click on the menu of any one of them to Edit or Delete it.
But, you can also add new muted defects by selecting any set of defects, at any scope, just click on any row to open child nodes.
After done, just click on Mute selected button to add those new ones to your list of Muted Patterns.
As before, message indicating to Recalculate will be shown.
If you run delivery analyses on an application, you could also mute defects in any delivery performed over the last baseline analysis. Once muted, those muted defects will be considered in further delivery and baseline analyses |
When you are at Life Cycle module, you can see the list of deliveries as in the image below.
In case you have muted defects, any delivery previously analyzed to the muting will have a warning icon indicating that audit was done before the muting so results may not match shown defects.
To mute defects on the delivery, just click on the Status icon of any delivery to open the Audit for it.
Afterwards, you can select Defects submenu and mute defects over the delivery defects list as in a delivery analysis.
You can mute defects then either at the New Defects or the Defects tab.
Here, you mute defects over the defects list as in a delivery analysis.