This guide will show you how to manage Kiuwan defects in four different scenarios.
Contents:
| Table of Contents |
|---|
Introduction
Kiuwan gathers evidences evidence from the 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 best programming practices”practices, from security to quality points of view. We call those evidences “evidence defects” (or “vulnerabilities”, if related to security).
| Info |
|---|
| The term “defect” 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. Our point is that However, depending on the scenario, it might happen that the identified defect is triggered by a rule that is not needed for a specific application. In this case, Kiuwan provides useful mechanisms to manage those similar 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.
Here is an explanation with an everyday scenario:
If a doctor (Dr. Kiuwan) 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 in the patient, these are no doubt defects if you follow best health practices. Dr. Kiuwan can detect this and raise a flag on it.
These defects are not applicable in every caseBut… 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. 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.
...
in the case of a patient with heart problems, the defect of lack of exercise is not needed. Dr. Kiuwan can change the priority of this defect or remove it completely.
Scenario 1: “This rule is not applicable at all
...
to my code”
...
| Info |
|---|
If you find that a Kiuwan rule Deactivate the rule if it does not make sense at all for your application, you should “deactivate” itthe application. |
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 on the browser.
But, some Some mobile applications are built using some frameworks (Cordova, for example) that generate javascript and html HTML code that do does not prevent the use of the 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 How can I deactivate a rule visit How to Deactivate a Rule for help on how to do it.
...
Scenario 2: “The rule is generally applicable, but this defect is not really a defect”
...
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” 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.
| Info |
|---|
In any case, you want Use the Mute Defect functionality to keep active the rule active but discard those specific defects. Kiuwan provides the Mute Defect functionality to do it. |
You can fine-tune this muting mechanism to suite suit 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 the Kiuwan indicators' calculations.
Please , visit Muting defects 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: “Some files should not be analyzed and defects found in those files should be not be raised”
...
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”open source, generated code or third-party code.
| Info |
|---|
You Exclude those files from the analysis if you cannot modify the source code, but their defects are decreasing the indicators of your application. In those cases, you should exclude those files 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” exclusion mechanism by which you can tell Kiuwan what files should not be analyzed (individually or matched by regular expressions) o or even what files only should only be analyzed.
You can visit Analysis Management and Code analysis usin the downloaded agent to Manage Different Analyses in Kiuwan and Advanced KLA How-Tos to see how to do it (in the cloud or locally, respectively).
Case 4: “Some rules would need to be adapted to my circumstance to properly work”
...
The Most of Kiuwan rules’ behavior can be customized. Kiuwan rules come with “default” 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.however, most of them can be customized.
| Info |
|---|
If you find that a rule does not exactly cover your needs, please look at its configuration parameters. It's likely that you find how to instruct the rule to suite suit your needs. |
Depending of on 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 Rules Management for further infoinformation.