Describe the Usage of SCA Tool Template

When a new static code analysis (SCA) tool has been chosen for a product or part of a product, it needs to be described to facilitate its use in the considered and other products.

This template contains the information that should be part of the documentation for each SCA tool. See Static Code Analysis Tools for recommended tools.

## Where to find the tool

(There shall be a description of where to find the tool, how to install it locally if applicable, and/or where to find it on a server.)

## Description

(Add a short description of the tool and its usage. Can it perform static or dynamic analysis? Does it support the formatting of the code? Which programming languages are supported?)

### Motivation

(What is the reason for choosing this tool in general or for a specific product?)

### How to analyze the code

(Describe how to perform the analysis in general. Describe how to handle 3rd-party code.)

### New and changed code

(Describe how to analyze new and changed code. Describe which rules can be skipped for which codebase, and which rules must be handled.)

### Existing code base

(Describe how to handle an existing code base; if it is possible to baseline issues on the existing code base, and only focus on new issues on added or changed code. Describe the baselined rules for each code base and the rules that must be handled.)

## New versions

(Describe how to update the tool with a new version. Also, mention who is responsible for performing the update.)

## Ruleset

(Describe how the ruleset configuration works in the tool. Consider the following subchapters:)

### Storage

(Describe where the ruleset can be found, e.g. is it a part of the code as a configuration file, or stored on a server?)

### Version control

(Describe how to handle different versions of a ruleset. It must be possible to know exactly which rules have been used for a specific version of a product. A configuration file placed with the code is one way of handling versioning, another way is to have a separate document under version control listing the rules.)

### Add/remove rules 

(Describe how to change the ruleset to add and remove rules.)

### New rule set from new tool version. 

(Describe how to update the ruleset when a new version of the tool has been provided. Also, mention who is responsible for updating the ruleset.)

### Standards 

(Describe if the tool can be mapped to for instance security rules to support security standards, e.g. to be compliant with IEC 62443-4-1.)

## Monitoring

(Describe how the issues found by the tool are monitored, how to detect new issues, how to find already handled and remaining issues, and how to display the severity of not handled issues. Is it possible to integrate the tool in the existing development environment, for instance, Azure DevOps?)

## Severity levels

(Describe the different severity levels of the issues for a specific tool. Some tools like SonarQube have different types of issues (bug, vulnerability, and code smell) and different severities (blocker, critical, major, minor, info). Klocwork only uses severity (critical, error, warning, review).)

## How to handle deviations

(Describe how to handle false positives and deviations from relevant and correct issues. How and where to add motivation for deviation.)