Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »


Kiuwan gathers evidences from application's source code using in-house developed static analyzers and rules.

During source code scanning, Kiuwan looks for patterns (bad smells) that are not conformant to widely accepted “best programming practices”, from security to quality points of view. We call those evidences “defects” (or “vulnerabilities”, if related to security).



The term “defect” has an obvious negative connotation. And some of our customers get worried when Kiuwan detects a “defect” but they do not see the reason for that. At that moment, customers used to contact us and we carefully study the case. 

Solutions come in different flavors: from an explanation to the customer of the reason of the defect (due to a misunderstanding of the rule), to a fix in the rule code to avoid a false positive.

Kiuwan provides useful mechanisms to manage those situations. All you need is to understand what situation is and what actions you can do.


An example might be helpful to understand the analysis process.

Let’s suppose that Kiuwan is a kind of “doctor” that checks the health of a patient. It “scans” the patient and, for example, detects overweight. That’s not a good point, and also it detects a lack of exercise and bad nutrition habits. Nobody could doubt about the convenience of those “best practices”. Therefore, the doctor, and similarly Kiuwan, detect it and raise a flag on it.

But… that “defect” (lack of exercise), although it is something to be alerted, might not be applicable depending on other circumstances. For example, it might not be applicable if the patient had a heart disease.  In that case, the doctor considers the case and decreases the “priority” of that “defect”, or even he throws it out.

This is only an example of my point in this post:


Kiuwan scans the code searching for broadly accepted “bad smells”. But, depending on specific circumstances, those defects could not be such. 

What to do in those cases?

Below I will go through the most common situations reported by our customers. For each of them, I will provide some action you can do.

As you will see, which one to apply will depend very much on your knowledge of the application code and, as always, on a deal of common sense.

Case 1: “This rule is not applicable at all  to my code” : Deactivate it from the model

If you find that a Kiuwan rule does not make sense at all for your application, you should “deactivate” it.

For example, there’s a common bad practice that is to allow the use of the back navigation button in a web application. It’s commonly accepted that you should “catch” the use of the back button and do not rely in browser.

But, some mobile applications are built using some frameworks (Cordova, for example) that generate javascript and html code that do not prevent the use of back button.  In these cases, the above rule does not make sense. It does not apply at all to the application, so the obvious solution is to deactivate it.

Please, visit for help on how to do it.


Case 2: “The rule is generally applicable, but this defect is not really a defect” : Mute that defect and report it to us

You could find that 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.  It could be that in some specific points the rule is not applicable, or might be false positives.

In any case, you want to keep active the rule but discard those specific defects. Kiuwan provides the Mute Defect functionality to do it. You can fine tune this muting mechanism to suite your needs:

  • Mute concrete defects in specifics source files
  • Mute a complete source file
  • Mute a rule

After muting, those defects will not be considered in Kiuwan indicators calculations.

Please, visit for help on how to do it.

In case you are muting a defect because you consider that “is not a defect” and the rule is not properly working (i.e. a false positive), please do not hesitate to contact us to report the issue. We will do our best to fix it as soon as possible.


Case 3:  Are there any files that should not be analyzed? Exclude them

Case 3: “Some files should not be analyzed and defects found in those files should be not be raised” : Exclude those files from the analysis


A very common scenario is when you are analyzing your code but you are obtaining defects in files that you cannot fix for whatever reason. Common reasons are because those files are “open source” ,  “generated code” or “third-party code”.  You cannot modify them, but their defects are decreasing the indicators of your application.

In those cases, you should exclude them from the analysis.

Does this mean to delete them from the source directory previously to run the analysis? Not at all, Kiuwan provides an “exclusion” mechanism by which you can tell Kiuwan what files should not be analyzed (individually or matched by regular expressions) o even what files should only be analyzed.

You can visit and to see how to do it (in the cloud or locally, respectively).


Case 3: “Some rules would need to be adapted to my circumstance to properly work” : Customize their behavior


Most of Kiuwan rules’ behavior can be customized.  Kiuwan rules come with “default” parameters, i.e. they work using “factory settings”.

As far as possible, Kiuwan configures the rules with reasonable default parameters. But we cannot cover all the different possibilities, so Kiuwan provides a mechanism to customize rules’ behavior.

Depending of the rule, the customization level can be different, so you should always consult the rule documentation to know the customization level and tune its behavior according to your needs.

Please, visit for further info.


  • No labels