> For the complete documentation index, see [llms.txt](https://docs.ox.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ox.security/ox-integrations/3rd-party-integrations/code-security-static-analysis/coverity.md).

# Coverity

## About Coverity

You can connect OX to Coverity to import the static analysis defects that Coverity Connect finds in your code. This lets you triage Coverity results in OX next to the rest of your findings, with the same severity model, ownership, and reporting.

Coverity is the static code analysis product from Black Duck (formerly Synopsys). OX reads your Coverity streams and their open defects through the Coverity API, maps them to your OX applications, and refreshes them on every scan.

After the connection succeeds, OX imports Coverity findings on the next scan and maps them to your OX applications. From there, they follow the same policies, severity model, and ticketing that your other findings follow.

User Name & Password is the only connection method for Coverity.

### What OX imports from Coverity

The Coverity connector belongs to the Code Security (Static Analysis) category. OX imports the static analysis issues that Coverity finds in your source code.

### Prerequisites

* Coverity Connect account: A user that can sign in to Coverity Connect and read defects. A read-only service account is enough.
* Coverity host URL: The base URL of your Coverity Connect server, for example `https://coverity.<customer-name>.com`.
* OX permissions: Permission to configure connectors.

### Step 1: Prepare a Coverity account \[Coverity]

OX authenticates to Coverity with a username and password. Create or pick an account that can read the streams you want to import.

1. Sign in to Coverity Connect as an administrator.
2. Create a service user, or choose an existing one, and grant it a role that can view defects on the relevant streams.
3. Confirm the account can open the stream list and see the defects.
4. Note the account user name, the password, and the server URL.

### Step 2: Connect Coverity to OX

1. In the OX platform, go to the **Connectors** page.
2. In the search box, enter `Coverity`.
3. Select the **Coverity** card under **Code Security (Static Analysis)**. The **Configure your Coverity credentials** box opens.
4. Enter the connection fields, as follows.

| Field             | What to use                                                                                                            |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Coverity Host URL | The base URL of your Coverity Connect server, for example `https://coverity.<customer-name>.com`.                      |
| User Name         | The Coverity account that OX authenticates as. Use a dedicated read-only service account rather than a personal login. |
| Password          | The password for that account. OX stores it encrypted and never displays it again.                                     |

5. Select **Verify Connectivity**. OX calls Coverity with the values you entered and reports whether the call succeeds.
6. Select **Connect**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ox.security/ox-integrations/3rd-party-integrations/code-security-static-analysis/coverity.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.