These days when customers ask how they can exclude code libraries from their analysis, we say, "WHAA-AAT?!" Why not use source code analysis to do a security assessment that includes all your sources, including third-party code at least once, and then at least sporadically for each patch to the library? The other benefit of analyzing your third-party code is to give the analysis engine a more complete view of your code base, which leads to more accurate results.
For example, the analysis may fail to report a memory leak in your code if the memory allocation functions are in a third-party library file that was excluded from the analysis.
And for the record, there's no way to exclude code from your Insight build analysis anyway. You're welcome. So, the question becomes, what do I do when the analysis detects problems in a code library that I can't fix? The answer is: If you see something serious, then report it. If not, then filter out the small stuff. It's that simple.
After you run your build analysis, Klocwork Review is where you see analysis reports and metrics, as well as lists of defects. There are two approaches you can take to filter out defects in third-party code: issue citing, or creating a view that excludes the code.
Cite defects with the "Ignore" status
In Klocwork Review, cite the defects in third-party code using the status "Ignore". By default, reports and lists exclude defects that are ignored. You'll never see these defects again--unless you search for them specifically. Of course, if the third-party vendor releases a patch, or you deploy custom checkers, and new defects are detected, then you WILL see defects in this code. Simply ignore these new issues and you're done. Here's a quick how-to with pictures:
1. In Klocwork Review access the issue list for your project:
2. In the search string, type the path to your third-party library to filter the list down to issues detected along that code path.
3. Click the All hyperlink above the list:
4. In the Status list, select Ignore. You may add a comment if you wish. Submit your change.
If you ever want to see issues that have been ignored, use this search string:
For more information, see Investigating and citing issues in the integration build. Create a module for your third-party code Creating a module is useful for both searching purposes in the issues list and for creating a view that excludes 3rd-party code defects from reports. In this section, we create a module that includes the path to 3rd-party code. Then we'll, use the module as a search parameter in the issue list. 1. If you're already viewing the issues for your project, click Modules in the top rail.
2. Click Create a new module.
3. Fill in the Module name fields and the Path patterns fields. When you start typing, the field auto-suggests paths for you.
- You can use asterisks as wildcards in your path patterns.
- To add more directories, click add.
4. Add a tag, if you wish. Tags are a handy way of sorting long lists of views.
5. If you have Project admin status, add a check to Public, so that anyone who logs in can see this view. If you don't make the view public, it's available only to the view creator.
6. Save the view.
This module makes it even easier to target or exclude detected defects from this library in your issue search results.
Example 1: Look for ignored issues in the lib module only
Example 2: Look for ignored issues in files other than the lib module:
Note: The hyphen excludes specified modules from the issue list.
Create a view that excludes third-party code regardless of status
In the instructions above, you saw how changing an issue status to something other than Analyze or Fixed excludes it from reports or issue lists. If you prefer to exclude all third-party code without citing it, you can use a view.
The prerequisite for this approach is creating a module for the third-party code (as shown above).
1. Click Views.
2. Click Create a new view and fill in the View name.
3. Type your search criteria. In this case, you want to exclude this module, so add a hyphen before the module keyword. Note: Refer to the instructions above regarding making a view public and adding tags.
4. Click Create.
Next, apply your view:
1. Click Issues or Reports.
2. In the list next to your project name, select your new view
This view acts as a persistent and selectable filter for your lists and reports. For more information, see Excluding issues in test code from view.
The downside is that you have to remember to select it when you want to apply the view. For any new view you create, you must remember to exclude that specific module if you don't want to see defects from that code reflected in reports or issue lists.
In short, be comprehensive in your analysis and selective with your filtering.