Copyright © 2020 Synopsys, Inc. All rights reserved worldwide.
Coverity Desktop is a supplemental Coverity Analysis tool that allows you to identify issues in your source code within the Visual Studio IDE. Analysis results from your code base are displayed in the Coverity Desktop plug-in to help you find and report hard-to-spot software defects, potential security vulnerabilities, and test policy violations. Note that Dynamic Analysis defects are not displayed in Coverity Desktop.
Coverity Desktop provides two analysis modes:
After Coverity Desktop displays your issue data, you can view the issues for your project marked directly in the IDE's code editor view. Coverity Desktop provides two views: Issues and Details. Use these views to navigate through your issues, to determine the impact of the issues on your code, and to manage and update (triage) the state of each issue.
Installation instructions and supported platform details are located in the
Coverity 2020.12 Installation and Deployment Guide
.
This guide provides the following information for Coverity Desktop for Microsoft Visual Studio:
Key concepts and use cases that describe typical end-to-end workflows.
Coverity Desktop Getting Started guide to walk you through configuration and running your first analysis.
Coverity Desktop user interface reference that details configuration settings, Issues view, and Details view.
It is assumed that you have a functional knowledge of the Visual Studio IDE, as well as Coverity Analysis, Coverity Connect, and Test Advisor concepts.
If you need more information, consult the following Coverity product documentation:
For more information about Coverity Connect, see the Coverity Platform 2020.12 User and Administrator Guide.
For more information about Coverity Analysis, see the Coverity Analysis 2020.12 User and Administrator Guide.
For more information about Test Advisor, see the Test Advisor 2020.12 User and Administrator Guide.
Coverity Desktop for Microsoft Visual Studio has the following requirements:
Coverity Connect 2020.12
Coverity Analysis 2020.12 (required for local analysis. Typically installed at the same time as the plug-in)
Visual Studio (refer to the "Coverity Desktop" chapter of the Coverity 2020.12 Installation and Deployment Guide for supported version numbers)
Memory requirements: the minimum is 3 GB of RAM and more if you use parallel analysis.
Refer to the
Coverity 2020.12 Installation and Deployment Guide
for more information.
Before getting started with Coverity Desktop, make sure that you also have the following Coverity Connect access information:
Host name
Port number and type (HTTP or HTTPS)
Authentication key file, or your user name and password for creating a new authentication key.
Stream name
![]() | |
This information is dependent on your Coverity Connect administrator configuring the server and running an initial analysis and commit. See the Coverity Platform 2020.12 User and Administrator Guide for information on configuring Coverity Connect for use with Desktop Analysis. |
This section provides conceptual definitions and use cases for Coverity Desktop. The point of this chapter is to help you decide how you would like to configure and run the Coverity Desktop tools to accomplish your tasks. After you decide on an analysis mode, see the subsequent chapters in this guide for information about server and analysis configuration, running a local analysis, and examining and triaging issues within the IDE.
Central Analysis. A central analysis occurs when the central source code repository is analyzed by Coverity Analysis outside of the IDE. Central analyses are typically run on a build server and are triggered by an automated process. In most installations, a central analysis will be run as part of a nightly build. Alternatively, a central analysis might be initiated whenever code is checked in to the source code repository.
The issues discovered by the central analysis are committed to a Coverity Connect database that Coverity Desktop uses to retrieve and update issue information that you view and triage within the IDE. Central analysis options, including server and stream information, are set using one or more Analysis Configurations. You must set up at least one analysis configuration to retrieve central analysis results in the plug-in.
Local Analysis. With local analysis, you analyze your source code for issues within your IDE. By running a local analysis, you can examine issues, fix issues, and verify that the issues are fixed before checking your code back into the central code repository. You have the option of analyzing a single source file, a set of source files of your choosing, or your entire project.
Local analysis options are set using one or more Analysis Configurations. Upon initial set up Coverity Desktop, you will have a default analysis configuration with your choice of analysis options. You may create additional analysis configurations, with different sets of options, and choose the correct configuration for each individual analysis run. This allows you to easily change the type of analysis you want to run, depending on the project or file(s) you are currently working on.
Before you begin using Coverity Desktop, there are a few important points to keep in mind. Local analyses will run on the files within your workspace. Whether you have run a local analysis or you are viewing remote issues from a central analysis, the plug-in will present a list of issues in the Issues view, and will also show issue markers alongside the defect occurrences in the source code editor. To help the analysis run smoothly and report accurate information:
Check the console view for output while running an analysis. Some non-critical warnings (such as number of missing classes) appear only in the console.
There may be files added to your workspace since your last build that are not available for analysis. In these cases, when you select an analysis option to run, Coverity Desktop will prompt you with several options in the Uncaptured Source Files dialog. Select Capture Build and Analyze to complete the analysis.
You may also preemptively capture a full build of your project, prior to attempting analysis, by using the Capture Build command in the → menu.
![]() | |
While Coverity Desktop displays issues reported by Test Advisor through Central Analysis, the plug-in does not support local Test Analysis. This means that you will be able to view and triage test policy violations retrieved from the Coverity Connect server, but not analyze local changes for newly introduced test issues. |
Analysis Configurations. Analysis Configurations are entities that define the analysis scope and set the options for local and central analyses. You must have at least one analysis configuration in order to use the plug-in, and you may also set up additional configurations for using different options and analysis scopes.
Each Analysis Configuration can be associated with a reference stream and snapshot from a central analysis on the Coverity Connect server. It is possible, and recommended, to use the analysis settings that are associated with the reference stream. However, you may also choose to pass additional analysis options, or exclude certain files from analysis through your analysis configuration.
Security analysis. Coverity Desktop can perform local security analysis using the security checkers, but requires running a whole program analysis. Be sure that the selected analysis configuration has the When running Analyze Scope, run all enabled whole program checkers option selected, from the → page.
The use cases described in this section provide a high-level workflow of how you can use Coverity Desktop within your organization. The use cases are:
All of the use cases below use the following user roles/personas to demonstrate a particular workflow:
Build Engineer
is responsible for the central code repository,
including using Coverity tools for Analysis Configuration, analysis runs, and committing the
results to a central Coverity Connect server.
IDE Developer
is a member of a software development team that uses
the Visual Studio IDE for development and Coverity Desktop to view and triage central analysis
and/or local analysis issue results.
Goal. IDE Developer wants to view and triage analysis results from the central source code repository.
The following diagram shows a high-level view of the process:
Build Engineer builds and runs Coverity Analysis on the central code base. (This process is typically automated on some regular interval, such as nightly).
Build Engineer (or automated scripts) commits the issue results to Coverity Connect. (Projects and streams are already appropriately configured to receive issue data).
IDE Developer configures Coverity Desktop to connect to the central Coverity Connect server.
IDE Developer checks out a section of the code for which he/she is responsible.
IDE Developer examines the impact of the remote issues in the code and triages them within the IDE.
IDE Developer fixes issues and checks the code into the central repository.
The nightly analysis runs.
Goal. IDE Developer wants to analyze and view defect results on his/her local code.
The following diagram shows a high-level view of the process:
Build Engineer builds and runs Coverity Analysis on the central code base. (This process is typically automated on some regular interval, such as nightly).
Build Engineer (or automated scripts) commits the issue results, along with function summary data, to Coverity Connect. (Projects and streams are already appropriately configured to receive issue data).
IDE Developer configures Coverity Desktop to connect to the central Coverity Connect server and configures local analysis settings.
IDE Developer checks out a section of the code for which he/she is responsible.
IDE Developer runs local analysis on selected file(s).
IDE Developer examines and triages the defects that were found by the analysis.
IDE Developer fixes a list of defects.
IDE Developer runs local analysis again to ensure that the defects were fixed.
IDE Developer checks the code into the central repository.
Goal. IDE Developer wants to see remote issues and also wants to use local analysis before committing code to the source repository. This ensures that the IDE Developer doesn't introduce any new defects into the source repository as a result of their changes.
Build Engineer builds and runs Coverity Analysis on the central code base. (This process is typically automated on some regular interval, such as nightly).
Build Engineer (or automated scripts) commits the issue results, along with function summary data, to Coverity Connect. (Projects and streams are already appropriately configured to receive issue data).
IDE Developer configures Coverity Desktop to connect to the central Coverity Connect server and configures local analysis settings.
IDE Developer checks out a section of the code for which he/she is responsible.
IDE Developer retrieves remote issues from the Coverity Connect server, and finds the file containing the defect to be fixed.
IDE Developer runs local analysis on the file to reproduce the defect locally.
IDE Developer fixes the defect in question.
IDE Developer runs local analysis again to verify that the defect is fixed.
IDE developer continues working on defects in individual files, or checks the completed code into the central repository.
This chapter provides you with the basic steps for retrieving remote issues and running local analyses. If you have not set up an initial analysis configuration, you will be prompted for pertinent configuration information as you perform these tasks for the first time. You can find more detailed information on the various Coverity Desktop views and features in their respective sections of Chapter 3, Analysis options and views.
Installation instructions for Coverity Desktop are located in the
Coverity 2020.12 Installation and Deployment Guide
.
Coverity Desktop allows you to view remote issues from central analyses on your Coverity Connect server. This section will guide you through the process of viewing remote issues in the Coverity Desktop plug-in. This section assumes that you have already set up an analysis configuration with a Coverity Connect connection and associated stream. See Chapter 4, Analysis Configurations Dialog for details.
![]() | |
You will only be able to view issues from source code files to which you have access. These files should also be present in your IDE's workspace. Otherwise, the file name associated with the issue will display in red in the Issues view, and the issue's source code will not be available for display in the editor. |
Navigate to
→ .This will open the Issues view in Remote Issues mode.
Double-click on any of the issues to display the issue details and open the Details view.
From here, you can triage and fix the issue directly within the IDE. See Section 3.3, “Issues view” for details on the Issues view filters and options. See Section 3.4, “Details view” for information about the tabs and fields in the Details view.
Local analysis allows you to locate new and existing issues for code that you have changed before checking it into your central code repository. This short tutorial will guide you through the necessary steps.
In order for local analysis to return the most accurate results, you must connect to a relevant stream on the Coverity Connect server. This will provide necessary interprocedural analysis summary information for fast, accurate analysis results. This will also allow issue triage information to be shared between Coverity Desktop and Coverity Connect. See Section 4.3, “Streams” for additional information.
![]() | |
This tutorial assumes that you have a project open within the IDE in one of the supported languages: C/C++, C#, JavaScript, Node.js, PHP, Ruby, and Python. |
Ensure that the source file you want to analyze is open in the main Editor pane.
Select Analyze Current Editor File from the
menu, or simply click the shortcut icon () on the toolbar. This will
save the current editor file if it has any unsaved changes.
![]() | |
You can also analyze multiple files in the same local analysis. To do so, use the Analyze Modified Files (SCM) option, via the menu or the toolbar shortcut. If you have configured your SCM for use with Coverity Desktop, this will analyze all source files that are new or modified since your latest checkout. If you have not configured your SCM, you can simply select multiple files manually:
|
Note that any source files that have not been previously captured in a build by Coverity Desktop will not be available for analysis. When you attempt to run local analysis on one of these files, you will be prompted with several options in the Uncaptured Source Files dialog. To proceed with analysis, select Capture Build and Analyze. This will capture a build of the entire solution, and then run the local analysis as requested.
Once the analysis is complete, the Issues view will be updated to reflect any issues in the code you've selected. Double-click on an issue to view and triage the issue from within the IDE.
You can associate different Solution/Platform Configurations to specific analysis settings by creating a unique Analysis Configuration for each unique Solution/Platform Configuration you want to analyze.
If the Solution/Platform Configuration needs to be associated with a specific Coverity Connect stream, make sure that you have selected the appropriate active Analysis Configuration, or create a new one with the correct stream setting configured. The current Solution/Platform Configuration build will always be analyzed using the currently active Analysis Configuration.
See Section 3.2.3, “Analysis scope options” for additional analysis options.
Coverity Desktop allows you to perform a local analysis on your source code from your IDE, so you can quickly pinpoint and fix issues before checking your code into a central code base. This chapter provides details on the various analysis options and views available in the plug-in.
Coverity Desktop adds several shortcuts to the Visual Studio toolbar, allowing you to quickly select and/or edit analysis configurations, or run a local analysis. The shortcuts are:
Table 3.1. Toolbar shortcuts
Shortcut | Action | Description |
---|---|---|
![]() | Analyze current editor file | Analyze the current editor file, using the settings specified by the active analysis configuration. |
![]() | Analyze modified files | Query the configured SCM to see which files have been modified locally, then run local analysis on those files, using the settings specified by the active analysis configuration. |
![]() | Analyze entire scope | Run local analysis on all the files specified in the active analysis configuration's analysis scope, using the settings specified by the analysis configuration. |
Drop-down menu | Active analysis configuration | Drop-down menu that allows you to select the active analysis configuration. You can also create a new configuration, or edit an existing configuration, from this menu. |
You can configure analysis options, retrieve remote issues, and run local analyses from the
menu.This menu contains the following menu items:
This item will switch the Issues view to Remote Issues mode, and populate it with relevant issues downloaded from Coverity Connect. These are the most recent issues in the central streams specified in the active Analysis Configuration.
See Section 3.3, “Issues view” for additional information on Remote Issues mode.
This option will attempt to build all of the source files in your current solution (based on the Visual Studio active solution configuration), and will capture the build under Coverity monitoring. Build settings can be configured under
→Note that it is not necessary for you to capture the build up-front, as you will be prompted to capture any unbuilt files on demand when running local analyses.
There are three ways that Coverity Desktop chooses which files to analyze with Desktop Analysis:
This option will run Desktop Analysis on the currently displayed source file. If there are any unsaved changes, the file will be saved when this option is selected.
SCM
>)This option will run Desktop Analysis on all of the source files that are new
or modified, relative to the code version most recently checked out
from the specified <SCM
>.
This option is not available if you have not configured an SCM system. See Section 4.4, “SCM”.
This option will run Desktop Analysis on all of the source files in your active Analysis Configuration's scope.
This option will run Coverity Desktop in a completely unconnected state. When in Offline mode, Coverity Desktop will not be able to download summary or triage data from Coverity Connect, and instead relies on any cached data from previous local analyses. As a result, analysis summaries may be out of date or nonexistent, and the results of local analyses could be less accurate.
![]() | |
Because local analysis requires summary data from Coverity Connect, Offline mode requires that the Coverity Desktop plug-in was previously connected to a Coverity Connect server, with a reference stream configured. Be sure that you are still able to connect with Coverity Connect when selecting Go Offline to allow the summaries to be downloaded in full. This will give the best results when doing offline analysis. |
This sub-menu allows you to open or close the following Coverity Desktop windows:
This option takes you to the Analysis Configurations Dialog, which contains important options and information for central and local analysis.
This option open the Coverity Desktop user guide.
The Issues view displays in one of two modes:
Local Issues mode displays the results of a local analysis. Note that the following screenshot shows the Local Issues mode with the "Show missing issues" option enabled.
Remote Issues mode displays issues retrieved from the Coverity Connect server.
![]() |
If the Issues view is not open, select
→ → .After running a local analysis or retrieving remote issues, the Issues view displays a list of the returned issues. It is possible that the list may be too large for you to effectively manage, or you might want to organize your issues in a manner that makes sense for your particular task. For example, you might want to list only the critical and open issues that are assigned to you. You can use filtering and sorting in the Issues view to focus the scope of your issues.
Each of the Issues view controls is described in Table 3.2, “Issues view buttons”.
Table 3.2. Issues view buttons
Button | Name | Action |
---|---|---|
![]() | Refresh | Retrieves the data for the current page of
issues and configuration information from the Coverity Connect server.
Local Issues mode. is not available in |
![]() | Re-run Analysis | Runs a local analysis using the same scope
and options as the most recently completed analysis. You can use this to verify that your changes have fixed existing issues, and have not introduced any new issues. |
![]() | Show/Hide missing issues | When enabled ("showing" missing issues),
issues that exist in the reference stream but are missing in the latest
local analysis will be displayed with a strike-through font, and no
triage information. Additionally, any issues that were newly discovered
by local analysis will be displayed in bold. Issues that exist both
locally and in the reference stream will remain in plain font. See Local Issues mode for an example.
When disabled ("hiding"), any issues that are missing from local analysis will not be displayed, and all existing issues will be displayed in plain font. This option is not available in Offline mode. |
After you select a manageable number of issues to view, double-click on an issue to open it in the editor. When you open an issue, the source code file that contains the issue opens in the source editor to the location where the issue occurs, placing markers that correspond to relevant lines. Additionally, opening an issue loads the current triage information for the issue in the Details view.
Issues are listed by CID, along with columns containing summary information for each issue, such as Classification, Severity, and so forth. You can change the order of columns by dragging the header to the desired position. To sort the ascending or descending order of each column label, click the column header.
You can also sort your list of issues and customize what columns are displayed through the Context menu. To display the Context menu, right click on a CID, or anywhere in the Issues view. Choose the Sort by menu choice to change the sorting order of the columns.
To add or remove a column, select Show Columns. To add a column, select the attribute. Note that the attributes that are available in the Sort by menu are controlled by those that you select in the Show Columns menu.
You can add, remove, or sort by the following columns:
Use the Sort by menu to sort the list of issues based on the following default categories:
Issue impact as determined by Coverity Connect: High, Medium, Low, or Audit.
The Impact value is displayed in the first column, and is represented by a colored icon (a blue 'down' arrow for Low impact, a yellow dash for Medium, and a red 'up' arrow for High) - illustrated in Issues view modes.
A numeric identifier for the essential characteristics of a defect that are unlikely to change from snapshot to snapshot. When two occurrences have the same CID, it is likely that both would be fixed by the same source code change. Triage is associated with the CID rather than any particular occurrence.
Internal signature used to merge separate occurrences of the same software issue and identify them all by the same CID.
The checker that reported the issue.
The user assigned to resolve the issue. You can change the owner that is assigned to the issue in the Details view.
Indicates the state of an issue. The available classifications are Unclassified, Pending, False Positive, Intentional, Bug, Untested, No Test Needed, and Tested Elsewhere. You can change the level assignment in the Details view.
Indicates an issue's magnitude of potential risk. The default severity levels are Unspecified, Major, Moderate, and Minor. You can change the severity level in the Details view.
Indicates how an issue is to be handled. The default categories are Undecided, Fix Required, Fix Submitted, Modeling Required, and Ignore. You can change the action in the Details view.
The targeted time frame in which the issue should be fixed.
An identifier (such as an issue number in a different database) specified by your company.
Displays True if the CID is a Legacy Issue, otherwise False.
The name of the component in which the issue was discovered.
The name of the function that contains the issue.
The file path that contains the issue. If the file is not located, the path displays in red text. If red text is displayed, go to the File Path Mapping dialog, and make sure that you have the proper definitions for stripping the remote path prefix and for adding the proper local path to search (if needed). The displayed path is the path known to Coverity Connect, the tooltip will display the local file path if the file is found locally.
The number of defect occurrences that all have the same CID.
The date of the analysis in which the issue was first detected.
The date of the analysis in which the issue was last detected.
Sortable in Remote Issues mode only.
The date of the last analysis in which a change was made to the issue's triage data.
Sortable in Remote Issues mode only.
Short description of the nature of the software issue.
Issue type. For example, Resource leak, Out-of-bounds write.
Indicates whether a CID is present in your reference stream.
Sortable in Local Issues mode only.
Programming language associated with the issue.
Appears if a custom attribute that accepts a text field exists in Coverity Connect. Sorting is done alphabetically.
Appears if a custom attribute with an ordered set of pick-list values exists in Coverity Connect. Sorting is according to the index of the pick-list element. That is, it is only ordered alphabetically if the list is ordered alphabetically in the Coverity Connect configuration.
To focus the scope of your issues in order to produce a more manageable work list, you can construct and apply a filter to one of your analyzed projects.
To apply a filter, select one of the following from the Filter drop-down menu:
A customized filter that you have created and saved.
After you have selected a filter, the issue list is updated with the matching results.
Pre-defined filters represent common search criteria to quickly focus your list of issues. You can add filter expressions, or edit the attributes and values in these filters to customize them. For information about editing pre-defined filters, see custom filters.
Coverity Desktop provides the following pre-defined filters:
Table 3.3. Built-in filter fields
Column | Description |
---|---|
All Issues | Displays all issues present in the current analysis. |
All Outstanding Issues | Displays all outstanding issues present in the current analysis. |
Fix Required | Displays all issues that have action - fix required. |
Found Today | Displays all issues that were found by the analysis for the current day. |
High Impact | Displays all issues that have an impact rating of High. |
Local Only | Displays only local issues that are not present in the reference stream. |
Major Severity | Displays all issues with a severity of Major. |
Missing Locally | Displays only issues that are present in the reference stream, but not found in the latest local analysis. |
Triage Needed | Displays all issues that are unclassified. |
My Outstanding* | Displays all outstanding issues that are assigned to the current user. |
Outstanding Defects | Displays all outstanding quality defects. |
Outstanding Security Risks | Displays all security vulnerabilities found by Security Analaysis. |
Outstanding Test Violations | Displays all Test Advisor policy violations. |
*. To modify the owner of the My Outstanding issues filter, manually set the Owner field to the user name of the person you want to own the issues listed as My Outstanding.
Customized filters allow you to configure one or more filters to restrict the number of issues you wish to be displayed in the Issues view. To construct your filter settings, select the edit filter... option from the Filter drop-down menu. This launches the Edit Filters window:
![]() |
To create a new filter, click the Name field. This is the name that will display in the Filter list in the Issues view. If there is a pre-defined or an existing saved filter that you want to be the basis for a new filter, highlight it and select the button to edit the filter's configuration.
button and enter the name of the filter in theFilters are made up of one or more filter expressions. A Filter expression consists of the following:
Describes an aspect of the analysis results for the issue. For example, you can specify user-defined triage states, a checker or issue type, and so forth. The attributes that you can define for a filter are described in Table 3.5, “Filter attributes and values”.
![]() | |
The attribute and value table does not include any custom attributes that might exist if they were created in Coverity Connect. |
Defines the criteria for how the value, related to its attribute, appears in the search. Each attribute will have a unique list of possible qualifiers from which you can choose, but each qualifier is described in Table 3.6, “Filter qualifiers”.
Represents a specific aspect of an attribute. Attribute values are described in Table 3.5, “Filter attributes and values”.
For example, the following filter expression, when it is saved and applied as a filter, will return only the issues that have a Classification of Bug:
Coverity Desktop allows you to construct more complex filters. The filter expression buttons allow you to add multiple filter expressions and nested filter expressions. The controls are:
Table 3.4. Filter expression buttons
Button | Action | Description |
---|---|---|
![]() | Add | Adds a filter expression at the
current level. There are two levels at which you can add a
filter, the top level and the nested level. New filter expressions created at the
top level are AND operators, so results are returned if they
match all of filter expressions that you add at that level.
Top-level filter expressions have to contain a unique filter
value. The Add button also creates new nested expressions at the same level as the previous nested expression (if one exists). |
![]() | Remove | Removes the current filter expression. If you remove a top level expression that contains nested expressions, all of those expressions are deleted. |
![]() | Add nested | Adds a new nested expression one level under the current top level expression. Nested expressions are OR operators, so results are returned for the current top level expression if the results match the top-level and any of the nested levels. All nested level expressions that belong to the same top level expression must filter on the same attribute. You can change the qualifiers and values. |
For example, the following filter expressions, when saved and applied as a filter, return any issues that match the following:
Any Classification value that is Unclassified
AND
Any Impact rating of High Impact
that has any of the following Action values:
Undecided
OR
Fix Required
OR
Modeling Required
The following table lists the default attributes and possible values that you can use in a given filter expression. Note that this table does not include custom attributes and values that can be created in Coverity Connect:
Table 3.5. Filter attributes and values
Attribute | Description | Values |
---|---|---|
Action | The action to be taken on the issue. | Undecided, Fix Required, Fix Submitted, Modeling Required, or Ignore. For definitions of the action values, see Section 3.4.5.3, “Action”. |
Category | Short description of the nature of the software issue. | A category chosen from a pick list. |
Checker | The name of the checker that reported the issue. | A checker name chosen from a pick list or a full or partial name of a checker entered by the user. |
CID | The CID (unique numerical representation) of the issue. | A number or range of numbers. |
Classification | The classification of the issue. | Unclassified, Pending, False Positive, Intentional, or Bug. Test Advisor specific classifications include Untested, No Test Needed, and Tested Elsewhere. For definitions of the classification values, see Section 3.4.5.1, “Classification”. |
Component | Displays issues that are contained in one or
more components to which you have access. Component filtering is CID-based, so an issue is included even if only one of its occurrences happens to be in the included component. Components that are invisible to users (through Access Control or exclusion) do not appear in the filter. For more information about components, see the Coverity Platform 2020.12 User and Administrator Guide. | A component name chosen from a pick list (if there is more than one) or a full or partial name of a component entered by the user. |
External Reference | An identifier (such as an issue number in a different database) specified by your company. | An external reference value chosen from a pick list or a full or partial external reference value entered by the user. |
File | The name of the file that contains the issue. | A full or partial file name entered by the user. |
First Detected | The date of the analysis in which the issue was first detected. | A date or a number of hours, days, weeks, or years. |
Fix Target | The targeted time frame in which the issue should be fixed. | Untargeted, or any custom value set by an administrator. |
Function | The name of the function that contains the issue. | A full or partial function name entered by the user. |
Impact | Impact is a rating of how the issue will affect your code or program. Some issue types have a greater impact on software stability than others. Filtering by impact allows you to view high impact issues first. | High, Medium, Low, or Audit. |
Issue Kind | Identifies the type of issue found. | Quality, Security, Test Violation |
Language | Programming language associated with the issue. | A Coverity supported programming language (C++, Java, etc.) |
Legacy | Specifies whether the CID is a Legacy issue. | True or False. |
Local Issue Status | Specifies whether the CID exists locally
and/or in the reference stream. This attribute only applies to local analysis results. | "Missing locally", "Local only", or "Present in reference". |
MISRA Category | The classification for MISRA issues | Mandatory, Required, or Advisory (If this choice is left blank, it is set to None.) |
Occurrences | The number of issues that have this CID. | A number or range of numbers. |
Owner | The owner of the issue. Coverity Desktop gives you a drop-down list of all available users on the Coverity Connect instance to which the plug-in is connected. By default, the owner is the current user. | A Coverity Connect username chosen from a pick list or a full or partial username entered by the user. |
Present in Reference | Indicates whether a CID is present in your reference stream. | True or False. |
Severity | The severity assigned to the issue. | Unknown, Major, Moderate, or Minor. For definitions of the severity categories, see Section 3.4.5.2, “Severity”. |
Type | Issue type. For example, Resource leak, Out-of-bounds write. | An issue type chosen from a pick list. |
The following table lists the qualifiers that are available to you when you construct your filter expressions. This table is a comprehensive list of the qualifiers. Attributes will only contain a certain subset of these qualifiers (based on the type of attribute):
Table 3.6. Filter qualifiers
Qualifier | Action |
---|---|
is | Includes the value for the attribute in the filter. |
is not | Includes all other values (excluding the value that is specified) for the attribute in the filter. |
contains | Include the value for the attribute if the value contains the characters entered in the text field. |
matches glob | Include the value if it matches any part of the entered glob
pattern. For example, if you choose the Checker attribute and
add FB.*NW* , the filter will return all available
checkers that contain "FB." and the characters "NW", such as
FB.UWF_UNWRITTEN_FIELD or FB.NP_UNWRITTEN_FIELD. |
starts with | Include the value for the attribute if the value starts with the exact characters entered in the text field. |
ends with | Include the value for the attribute if the value ends with the exact characters entered in the text field. |
is in the range | Select a range of two dates or numbers. |
is greater than | A range that is greater than the number you enter. |
is less than | A range that is less than the number you enter. |
is after | Select a single date. Returns values that occur after the specified date. |
if before | Select a single date. Returns values that occur before the specified date. |
is today | Returns the values that match the current date. |
in the last | Returns the values that match the specified number of hours, days, weeks, or months. |
not in the last | Returns the values that do not match the specified number of hours, days, weeks, or months. |
When you right-click on an issue in the Issues view, the context menu is displayed. From this menu, you can use the following options:
Select an attribute for sorting the list of issues.
Select which columns to display in the Issues view.
Displays the issue in Coverity Connect via your default browser. This option is not available when multiple issues are selected.
Copies the currently selected row so you can paste it as a text string into an email message, bug report, and so forth.
attribute
>Defines an attribute value for Classification, Severity, Action, and so forth. This is a quick way to triage your issue without having to use the Details view. You can select multiple issues and set the triage value for all of the selected issues at the same time. If a value is greyed out, that means it is an invalid value for the Issue Kind(s) of the selected issues.
The Details view allows you to manage an issue. For example, you can assign an issue's classification, severity level, owner, or add a comment. The Details view is not populated until you double click an issue in the Issues view.
![]() | |
The attributes described in this section represent the fields that are available to you by default. It is possible that there are additional attributes and values created as custom attributes in Coverity Connect. |
Use the next/previous issue buttons at the top of the Details view to display the next or previous CID in your list.
The top of the Details view describes the category of the
issue discovered by the Coverity Analysis checker and provides a description of the issue. It
also provides a link to the relevant SpotBugs documentation (if applicable) and
cross reference to the industry standard Common Weakness Enumeration
(CWE). CWE is extremely useful for further research on
the impact of your issue. It provides detailed descriptions and examples of the
issue type.
To triage an individual issue, update its various attributes by completing the following steps:
Assign the issue an owner by selecting his/her username from the Owner drop-down menu.
Set the issue's classification, severity, and action to be taken by selecting the appropriate values from their respective drop-down menus.
![]() | |
For detailed information on the issue attributes you can triage, see Section 3.4.5, “Issue attributes”. |
After you have triaged the issue attributes, click
. Your applied triage state is updated in Coverity Connect. You can also click to apply the changes and move on to the next issue in the list.The Occurrences tab shows the stream in which the occurrence of the issue is located, lists the name of the event(s) that lead to the issue for each category, and the filename and line number where this event was detected. Click the event name to go to the event in the source editor.
You can also browse through the next/previous occurrence of the CID (if more than
one occurrence exists) by using the arrow controls labeled Occurrence 1 of
<n
>.
Coverity Desktop provides tags that highlight the line where the event appears in the code. Tags that are associated with red markers indicate events and messages that are directly related to the issue. Tags that are associated with green markers indicate conditional branches and the programmatic decisions necessary for this issue to occur. When you double click a marker, the source editor focuses on the section of code in which the event occurs. Coverity Desktop provides the following markers:
Table 3.7. Issue markers
Marker | Description |
---|---|
![]() | Issue main event. |
![]() | Issue event. |
![]() | Multiple issue events that occur on the same line. |
![]() | Path event (True branch). |
![]() | Path event (False branch). |
Each time an attribute is changed or a comment is added, the user responsible for that change is stored in the database, and the listing on the bottom of the issue summary is updated to reflect the modification history. Click the History tab to see the complete history of the modifications.
You can set the classification, severity, action, and owner for each issue. These
issue attributes are intended to tell only part of the story; if an issue is marked
as a Bug
, for example, you might also want to document the
reason in the designated text area for comments. The issue attributes are useful to
restrict the issue list you are viewing.
Table 3.8, “Classifications” lists descriptions for each of the possible issue classifications, along with the Issue Kind(s) each classification can be attributed to.
Table 3.8. Classifications
Classification | Description | Issue Kind(s) |
---|---|---|
This attribute is the default when a new result is inserted. It is intended for results that have yet to be viewed by a developer. | Quality, Security, Test Violation | |
An issue that has been examined, but has yet to be conclusively classified. | Quality, Security, Test Violation | |
Results that are not real issues in
the code. If these appear to reflect shortcomings or flaws in
the analysis engine, report the issue to
software-integrity-support@synopsys.com . | Quality, Security | |
Designates that analysis has accurately diagnosed behavior that is usually unintentional, but in this scenario is actually the intended behavior. | Quality, Security | |
Reflects a determination that the issue found by Coverity analysis is an issue in the code, and is not a False Positive or Intentional. | Quality, Security | |
Reflects a determination that a section of the code analyzed by Test Advisor requires that a test be added to the code. | Test Violation | |
Reflects a determination that even though the Test Advisor analysis found a section of code that is not covered by a test, you are aware of the violation and that there is an accepted reason that the code is not covered. | Test Violation | |
Indicates that a section of code is tested outside of the set of tests that are specified in the Test Advisor analysis process. | Test Violation |
Severities for issues describe how critical the issue is, that is, how much damage the issue will potentially cause to your program. Coverity Connect allows you to add, delete, and rename severity issue attribute values. Coverity Desktop displays these customized attributes if they exist in the most current snapshot. For more information, see the Coverity Connect User Guide. The default severity attributes are:
This attribute is the default when a new issue is inserted. It is intended for those results that have not been viewed by a developer.
Issues that have been confirmed as major reflect a decision that the bug is of the highest level of urgency. It is probable that major severity bugs should be fixed as soon as possible.
Issues that have been confirmed as moderate severity bugs that should be fixed in the near term.
Issues that have been confirmed as minor severity bugs are perhaps of lesser priority.
Actions describe what should be done about the issue in question. Coverity Connect allows you to add, delete, and rename action issue attribute values. Coverity Desktop displays these customized attributes if they exist in the most current snapshot. For more information, see the Coverity Connect User Guide. The default action attributes are:
This attribute is the default when a new issue is inserted. It reflects that no decision about fixing or ignoring has been made.
The issue is outstanding and requires a fix; such an issue will continue to appear in future commits.
The issue is fixed in the source code, but the fix has not been identified as Fixed through the build, analysis, and commit processes.
An investigation is required of each method in the application that is used for interprocedural analysis, created as each function is analyzed. For example, the model shows which arguments are dereferenced, and whether the function returns a null value. This can be a form of false positive in which after the modeling is corrected, the analysis will no longer report this issue.
The issue can be ignored. This might be an appropriate action for a bug of minor severity.
You can provide an external reference (such as an issue number in a different database).
The Coverity Desktop plug-in integrates with Test Advisor, allowing you to view and triage test policy violations along with your other Coverity issues. To display Test Advisor issues, set the Issues View to Remote Issues mode, and Filter by Outstanding Test Violations.
Test Advisor issues, such as coverage, impact, and exclusion data, are represented with various annotations in the left gutter of the text editor pane. See Table 3.9, “Test Advisor annotations” for a description of each. For function level test violations, only coverage data for the relevant function is displayed. For file level test violations, coverage data for the entire file is displayed.
Table 3.9. Test Advisor annotations
Icon | Description |
---|---|
![]() ![]() ![]() | Hover over the green bar(s) to see a list of tests which cover the line. | - Green bars denote that the line or function is
covered by one or more tests. The number of bars indicate the code age
for the line, with one line for older code, two bars for medium, and
three bars for newer code.
![]() ![]() ![]() | - Red bars denote that the line or function is not covered by any test. The number of bars indicate the code age for the line, with one line for older code, two bars for medium, and three bars for newer code. |
![]() | Hover over the grey bar to see the reason for exclusion, if one was specified. | -
Grey bars denote that the line has been excluded from consideration by
Test Advisor.
Month DD,YYYY
| On function and class definition lines, you can hover over the date to see additional impact information or click the link to View in Coverity Connect. If the information listed in the pop-up is insufficient, Coverity Connect provides additional data and a richer interface for working with coverage issues. See the Test Advisor 2020.12 User and Administrator Guide for more information. | -
Displays the most recent impact date for the line, class, or function.
This view displays information about the intermediate directory associated with the most recent build of your project. To access this view, navigate to
→ → .This view also gives you the option to delete the intermediate directory, or delete your source code from the intermediate directory.
This menu option opens the Collect Diagnostics view, which helps you create a zip file of diagnostic information for the active Analysis Configuration.
![]() |
Analysis options and Coverity Connect server information are provided to Coverity Desktop through grouped settings known as analysis configurations. Upon installation of the plug-in, you will have a default analysis configuration in place, which requires some additional settings and connection information to be used for analysis. You may also choose to create additional configurations, to toggle between different options or streams from analysis to analaysis.
The Analysis Configurations Dialog, accessible via the Coverity Desktop toolbar or New Configuration from the Active Configuration drop-down, choose a name for the configuration, and then fill out the appropriate information in each of the dialog's subsequent tabs. Optionally, when creating a new configuration, you can copy the settings from an existing configuration (if any) and then edit them in place. The following sections contain details for each of the configuration tabs.
→ menu item, allows you to create and edit analysis configurations for Coverity Desktop. To create a new configuration, select![]() | |
To edit an existing configuration, select its name from the Active Configuration drop-down, and update the information in the configuration tabs accordingly. Additionally, the Edit Configurations option (in the Active Configuration drop-down) allows you to rename or remove any existing analysis configurations. |
Many of the fields in the Analysis Configurations dialog
are accompanied by a small grey (or black) "reset box". When you hover over
these boxes, they will display how the value was configured (either locally
configured, inherited from a coverity.conf
configuration
file, or the Coverity Desktop default value). If the box is black, this means that the
value has been set locally. To reset to the original value, click on the box and
select Reset. This will use the value specified by the
coverity.conf
file, if one exists, or reset to the
Coverity Desktop default.
See the Coverity Desktop Analysis 2020.12: User Guide for more information on
coverity.conf
.
The General tab, as shown in Figure 4.1, “General tab”, specifies the disk locations of your Coverity Analysis tools, including license files, as well as your code base directory. This information is required for running local analyses and creating authentication key files for connecting to Coverity Connect (see Section 4.2, “Coverity Connect” for details).
The full path to your Coverity Analysis installation directory. This is required for local analysis.
The location of your license.dat
file, which contains
your existing Coverity Analysis license. The default location is
<install_dir>
/bin
.
The plug-in will store additional Coverity configuration information in the
specified directory, as well as look for a
coverity.conf
file here. The
coverity.conf
file may be created by your Coverity Connect or
analysis administrator, and used to specify configuration information common
to all developers. See the Coverity Desktop Analysis 2020.12: User Guide for additional details.
The Coverity Connect tab specifies server and authentication information for the Coverity Connect instance relevant to each analysis configuration. This information is required for local analysis, and for retreiving remote issues.
The fully qualified URL for your Coverity Connect server.
This should include protocol, host name, and port number; for example, https://connect.synopsys.com:8080
.
If you are connecting to a Coverity Connect server over SSL, using a certificate signed by a recognized CA,
the host name needs to match the name of the host on the certificate.
This is not necessary when you use an unsecured connection,
or when you use a self-signed certificate from Coverity Connect.
Turn on this check box to validate the certificate. We recommend that you do turn it on. For additional details, see "Using SSL with Coverity Analysis" in the Coverity Platform 2020.12 User and Administrator Guide.
This field displays information about any existing authentication key file for the specified Host name and Port.
If authentication fails, or no authentication key exists, you will be prompted to import or generate a new key file. You can generate a new key by clicking the
link and entering your username and password. You can also import an existing key by clicking the link and choosing a key file that’s already been created or saved.If you attempt to import or generate a key when a key file already exists, then a
dialog box appears, prompting you to either the old key file or to .Click this button after entering all connection information. This will test the connection and validate your settings.
The Streams tab allows you to specify any relevant streams for which you want to view and triage remote issues, as well as select a reference stream and snapshot for local analysis.
Specifies the streams that contain issues you want to view and/or triage. Click the Add button to open the Select Streams dialog, which displays a list of all available streams for you to choose from.
Note that all selected streams should use the same triage store.
This will take you to the File Path Mapping tab.
Select the reference stream that the analysis configuration will use for local analysis.
This will take you to the Reference Snapshot tab.
The SCM tab is an optional configuration, which specifies any SCM information for the current project/analysis configuration. This is required only if you want to use the Analyze Modified Files command for local analysis.
Select your source code management system from the drop-down menu. The following SCM systems are currently supported:
Accurev
Clearcase
CVS
Git
Mercurial
Microsoft ADS
Microsoft TFS
Perforce
Plastic
Plastic (distributed)
Subversion
This is the executable for querying the specified SCM. To be used, the SMC must be installed in the command PATH.
This is the path to the root of the source repository.
This is a sequence of additional command line arguments to pass after the executable ("tool") name.
The protocol, host name, and port number of the Perforce server, in the
format
"<
". protocol
>:<host
>:<port
>
The <
is either
protocol
>tcp
or ssl
.
The name of the Perforce Client, as typically shown in the P4CLIENT environment variable. This is also known as a workspace name.
The location of the central Plastic server. This should be in the format of "<repository>@<remote-server>:<port>"
.
This field is required.
If needed, the arguments that will be passed directly to 'cm replicate'. Arguments include, but are not limited to, --user
and --password
.
This field is optional.
The Advanced configuration tabs allow you to configure additional build and analysis options for more advanced use cases.
Select whether to build your workspace using the built-in MSBuild engine, or specify your own build/clean commands.
This option depends on your selection of the
option.If you choose to use the built-in build engine, you will have the option to choose the specific build engine from a drop-down menu.
If you choose to use custom build settings, you will need to specify your own clean and build command, as well as your project's working directory.
This field allows you to use the --record-with-source
option with your build process.
This causes the build to also capture header file dependencies, which increases the breadth of your
analysis, but may also slows down the build process considerably.
This field allows you to specify additional options to pass to the build command.
See the Coverity 2020.12 Command Reference for information on available cov-build
options.
Your checker settings will be automatically selected by default, but you may choose to customize the list of configured checkers for analysis.
If you or your organization use customized checkers that were developed using the Coverity Software Development Kit, you can specify the location of the checkers. When you specify these checkers, they will appear in the list of checkers that you can enable through the Configure Checkers dialog.
This allows you to enable specific checkers for local analysis, and see detailed information on each one. Some checkers have additional options available, which you can configure by clicking
Options passed to cov-run-desktop
for local
analysis. These are inherited from the coverity.conf
file. See
the Coverity Desktop Analysis 2020.12: User Guide for more information on coverity.conf
.
Specifies any additional options to be passed to
cov-run-desktop
during local analysis.
These options will be added to those listed under the Cov-run-desktop options field. If there is a conflict, the options specified here take precedent.
This is a general option that you can enable coding standards checkers for security and quality checkers of the selected coding standard configuration file(s). You can either use one of our provided configurations (found in <install_dir>/config/coding-standards
) or you can choose to specify your own custom configuration file.
Imports Microsoft Visual Studio Code Analysis (MSVSCA, also known as
FxCop) results so that they can be viewed and triaged in Coverity Desktop. In
order to import MSVSCA results, the MSVSCA analysis must be completed
before you run the Coverity Desktop analysis. MSVSCA results are displayed
similarly to other Coverity Desktop issues, but the checker name has a prefix
of MS.*
.
You can enable Microsoft Code Analysis as part of the build process under the Code Analysis page of the C# Project Properties editor in Visual Studio. To ensure that Coverity Desktop imports the most recent results, this flag should be checked.
![]() | |
To avoid negatively impacting local analysis run time, you can make an alternate Analysis Configuration (named MS_AC for example) with Microsoft Code Analysis enabled. Then, when you need to see your Microsoft Code Analysis results, set your active Analysis Configuration to MS_AC and run your analysis as usual. |
This will take you to the File Exclusions tab.
N
> processor coresSpecifies the number of cores to use for parallel analysis. The default is the smaller of the number of cores on the machine and the number allowed by the license file.
The Scope tab allows you to restrict your local analyses to specific files and directories. Use the file tree to select which source files to analyze with the active analysis configuration. To analyze all of the files specified, use the Analyze Entire Scope option.
The Reference Snapshot tab lets you select which reference snapshot to use for local analysis. It is recommended that you use the Automatically select snapshot option. This should provide the most accurate analysis results, by using the snapshot closest to the version of the code being analyzed. Alternatively, you can choose to use the latest snapshot in the reference stream, the last snapshot committed before a certain date, or choose a specific snapshot ID.
The File Exclusions tab lists any files or filepath patterns that should be excluded from local analysis. To add a file exclusion, click the Add (+) button and enter the file path or glob pattern to exclude.
The File Path Mapping tab allows you to translate between remote and local file paths. With path translation, you can configure Coverity Desktop to strip a specified path prefix, and then search local paths for matching files.
In the event that the plug-in cannot resolve the path mapping or locate a source code file locally, the filename will appear in red in the Issues view, and you will not be able to view the issue in the source file.
The Workflow tab gives you the option to send analysis results to the Coverity Connect server.
Selecting this box will commit a new snapshot, containing all issues found by local analysis, to the Coverity Connect server associated with the analysis configuration. This option will only run by selecting the Analyze Entire Scope command and only if the When running Analyze Entire Scope, run all enabled whole program checkers option is enabled on the analysis page.
You can specify a Snapshot Description in the text field, and click the button to configure any additional commit options.
![]() | |
If this option is enabled for an Analysis Configuration, running local analysis with that Analysis Configuration will not display any CIDs or triage information in the IDE. Likewise, when you choose this option, analysis is disconnected from the Coverity Connect snapshot. Therefore, the analysis options included in the reference snapshot are not used. |
The following variables are supported in the Coverity Desktop UI:
${env_var:<
- Substitutes corresponding environment variables.ANY_ENVIRONMENT_VARIABLE_NAME
>}
${Solution}
- Substitutes the solution folder names
(where the solution is located) and the .cov
subdirectory.
This includes the trailing backslash. For example:
c:\MySolution\.cov\
${SolutionRoot}
- The full path to the solution folder,
where the solution (.sln
) file is located. This includes
the trailing backslash '\
'.
${cov-inter-dir}
- The full path to intermediate
directory. This includes the trailing backslash. For example:
c:\Users\me\workspace\.metadata\coverity\server8080mycode\
${cov-im-user}
- The Coverity Connect username.
${cov-im-password}
- The Coverity Connect password.
${cov-im-host}
- The Coverity Connect host name.
${cov-im-port}
- The Coverity Connect data port. The default is
9090.
${cov-im-auth-key}
- The full path to the Coverity
authentication key file.
${cov-sa-bin}
- The full path of the Coverity Static
analysis \bin
directory. This includes the trailing
backslash. For example:
c:\
<install_dir>
\bin\
${active-build-configuration}
- Expands to the selected
Visual Studio configuration. Strips all whitespace and special characters, and
all characters will be made lowercase. For example, Debug
becomes
debug
.
${active-build-platform}
- Expands to the selected Visual
Studio platform. Strips all whitespace and special characters, and all
characters will be made lowercase. For example, Any CPU
becomes
anycpu
.
This troubleshooting section provides instructions for fixing the following common issues with Coverity Desktop:
These errors may include:
error VCBLD0010: project requires upgrade
error MSB4036: "VCBuild" task was not found
Be sure that you have logged into the Coverity Connect server using the full LDAP username format:
<user
>@<domain
>.
This situation occurs if a file specified for analysis is not among those that Coverity Desktop recognizes as having been compiled during the build capture. Try the following potential solutions:
In the case that the files in question are never captured because they are not actually part of the project (and so not meant for analysis), proceed with your analysis by clicking
.It may also be useful to exclude these files from all future analyses. To do so, check the box to always ignore the files in question, or navigate to File Exclusions window, where you can specify any files you want excluded from your local analyses.
→ → .This will open theIt is possible that the file you are attempting to analyze
uses a compiler that has not yet been configured in Coverity Desktop.
If this could be the case, please run the cov-configure
utility to configure the compilers that are used by your project
(see the Coverity 2020.12 Command Reference for more information).
After adding any new compilers, be sure to recapture the build by selecting Capture Build from the Coverity menu, and try the analysis again.
If the file you are attempting to analyze is a non-PSF, such as a header file,
then it is necessary to use the --record-with-source
option for the
build capture. Navigate to → → and select Use --record-with-source.
After selecting the --record-with-source option, be sure to recapture the build by selecting Capture Build from the Coverity menu, and try the analysis again.
If none of these solutions resolve the issue, contact software-integrity-support@synopsys.com
.
This is likely caused by a discrepancy between remote and local file paths. To fix this, make sure that your file path mappings are configured correctly:
Navigate to
→ → .In the first box, enter the incorrect path prefixes to be stripped (displayed in red in the Issues view).
![]() | |
You can click to see an example scenario for using File Path Mapping. |
In the second box, enter the local paths you want to be searched in place of the stripped paths.
Click
to save and exit.X
>" has analysis summaries...If the SCM analysis option was used, and the codebase has a last updated date before the reference snapshot was committed to the stream:
Update your codebase and push the changes (so your SCM repository will be last updated after the snapshot was committed).
Re-run SCM analysis again on the newly updated codebase.
If you are working with an instance of Coverity Connect that uses a self signed certificate, you will need to ensure that the certificate is trusted by Internet Explorer. To do so, complete the following steps:
Open Internet Explorer
![]() | |
You must run IE as an administrator to complete the following steps. |
Navigate to Coverity Connect, at
https://<
hostname
>:<port
>.
Select Continue to this website, when prompted.
Select the certificate error in the navigation box.
Select View Certificate.
Click
.In some configurations, using the
option may not be sufficient. If you complete these steps and are still unable to securely connect with the server, complete steps 1-5 above, then follow the process below.From the Certificate view dialog, select the Details tab and click .
Complete the Certificate Export Wizard to save the certificate to a temporary location.
Open Microsoft Management Console (MMC) and navigate to → .
Double-click on the Certificates snap-in to launch the Certificates snap-in wizard.
Select Computer Account and click .
Select the Local Computer option and click .
Click Add or Remove Snap-ins dialog.
to close theIn the explorer pane, navigate to
→ .Right-click on the Certificates folder, and select → .
Use the wizard to import the file saved in step 2.
Close and re-open Internet Explorer.
Navigate to Coverity Connect, at
https://<
hostname
>:<port
>.
Internet Explorer should no longer raise any security certificate warnings.
If the certificate is not correctly signed, the connection will continue to fail. Ensure with your Coverity Connect administrator that the signature is properly formatted, with the First and Last name field set to the hostname or ip address for Coverity Connect.