Coverity on Polaris Terminology

Note: This platform is renamed Coverity on Polaris. Unless otherwise specified, references to Polaris or Polaris Software Integrity Platform in this documentation are referring to Coverity on Polaris.

Some definitions are unique to Polaris.

An application is a group projects created by a Polaris organization administrator or application manager in order to combine the data from projects in different repositories. This allows members of the application to see an aggregated view of results for the application and also the results for each of the constituent projects. Applications are limited to 200 projects.
Black Duck Security Advisories. Provides more actionable information, including remediation, scoring, and technical information surrounding the vulnerability. BDSAs also include theoretical exploit information and proven exploit information as well as remediation information.
When you use the -w flag, Polaris CLI waits for analysis to finish before proceeding with other commands. Waiting is sometimes known as blocking mode; likewise, when you run analysis without the flag, you are using non-blocking mode. (You should always use the -w flag when running analysis locally with the Polaris CLI.)
Same meaning as in source code management tools like Git. A duplicate version of an object under source control. 
Common vulnerabilities and exposures. A system that provides reference numbers to publicly known information security vulnerabilities. Maintained by the National Cybersecurity FFDRC.
Common weakness enumeration. A list of frequently occurring defects in software and hardware security, maintained by the National Cybersecurity FFDRC.

Dynamic application security testing. A solution that tests code while it runs. Tinfoil is a DAST solution.

default branch
Initially, this is the same as your main-for-project branch, which you can change independently to display project issues for all users in the Polaris Web Interface or, for incremental analysis, in the Polaris CLI via variables or the yaml file. These changes do not affect the main-for-project branch.
Fuzz testing uses deliberately malformed inputs to test software while it's running. If the system attempts to parse a fuzzed message and returns an error, this indicates a vulnerability in the code. Defensics is a fuzzing solution.
Consists of users. Groups can be organized hierarchically to model complex organization structures.

Interactive application security testing. A solution that uses dynamic testing against a running web application. IAST usually involves the installation of an agent that can monitor an application and identify vulnerabilities in real time. Seeker is one such solution.


A container for the output of the build and analysis phases of Coverity static analysis. The idir contains two subdirectories:

  • emit -- for build output (comprising source code, ASTs, and other compilation artifacts)
  • output – for analysis output (comprising defect records, analysis summaries, and other analysis outputs)
Not defined in Polaris documentation, but it is any problem detected by a SIG product requiring user investigation. (Because Polaris will integrate many SIG products, it has to assume a comprehensive view of what an issue is.)
issue type

The issue's name. For example 'Cross-site scripting' or 'SQL injection.' Issue types are categorized using taxonomies.

See scan.
JSON web token. Every request to the Polaris API must be accompanied by a JWT. To find out how to get a token, go to API Getting Started > API Primer.
Local analysis uses an instance of Coverity installed on the same machine as the Polaris CLI. Central analysis makes use of an instance on the Polaris server.
main-for-project branch
Each project has one branch with this designation, which is the first branch that the Polaris CLI runs an analysis on. It is displayed in Applications in the Polaris Web Interface. It can only be changed in the Polaris API by updating another branch and settings its main-for-project flag to true. The CLI treats it as the main branch while running incremental analysis if no other branch is found.
Consists of users and groups.
organization administrator
The organization administrator manages users, groups, and SAML integration. Same as organization owner. 
Open Web Application Security Project. A non-profit foundation that focuses on application security.
preferred branch

The individual user's preferred branch for viewing a project's issues in the Polaris Web Interface.

Corresponds to a single source code repository. A collection of binary artifacts to be analyzed. 
project administrator
Manages users and access. Can make changes to the project.
project contributor
Can perform triage and analysis.
project observer
Has read-only access to the project.
properties (or project properties)
Properties are key/value pairs designated by any contributor to the project. They're useful if you want to associate your project number or other internal identifiers with the project. Each project can have up to five project properties.
A snapshot of the project at a point in time. Corresponds to a commit in SCM.
See scan.
Security Assertion Markup Language. An XML-based language for sharing security-related information between domains. It makes single sign on (SSO) possible.

Static analysis security testing. A solution that analyzes source code without executing it and finds security vulnerabilities. Coverity is one example a SAST tool.


Software composition analysis. SCA describes solutions that scan code and detect the presence of known software libraries written either by open source projects or vendors. After scanning code, an SCA application helps to manage any security, quality, and license compliance risks associated with the libraries it discovered. Black Duck and BDBA are SCA solutions.

Execution of a tool or the attempt to execute a tool in Polaris. When a scan succeeds the results are associated with a run id. When a scan fails, a job id is available, but not a run id.
service account
In Polaris, an account that is used only for scripted access to the API. A service account is used to incorporate Polaris into your continuous integration process.
The value can be high, medium, low, or audit. Audit is reported if you are running Coverity analysis with audit checkers enabled. Issues with audit severity show a possible security vulnerability with only partial evidence. They require a manual review for complete evidence.
Single sign-on. A service that allows a person to sign in one time and receive authorization for multiple apps.
taxon (plural taxons or taxa)

A category or sub-category in a taxonomy, for example Security Misconfiguration is a taxon in the OWASP Web Top Ten taxonomy


A categorization of issues by issue type. Not all issues are included in all taxonomies. Some example taxonomies are 'OWASP Web Top Ten' and 'Common Weakness Enumeration'. Taxonomies are composed of a hierarchy of taxons.

tool domain

A classification of similar tools that are usually used for the same purpose. Synopsys SIG tool domains include the following: SAST, DAST, IAST, SCA, and Fuzzing.

Involves the user's decision to dismiss an issue, or not. When issues are dismissed the potential reasons are False Positive, Intentional, and Other (requires an explanatory comment).
Any individual with access to Polaris. Users can belong to multiple groups.
A callback that notifies a third-party service when an event happens in Polaris. For example, you could set a webhook to call an external API when a scan finishes successfully.