> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pharussecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Remediation tickets

> Connect Azure DevOps, Jira or GitHub, open a ticket for an incident or a finding, and follow the fix from Pharus.

<Info>
  **Plans:** Core and Plus, and the free trial. **Who:** owners and admins connect issue trackers; any member opens,
  links and unlinks tickets.
</Info>

The CRA asks for vulnerabilities to be fixed without delay (Annex I Part II(2)). Your engineers track that work in their
own issue tracker. Pharus opens the ticket for them from an incident or a finding, then reads its progress back, so the
incident shows where the fix stands.

Pharus writes a ticket once, when it opens it, and afterwards only reads it. A ticket closed in the tracker is evidence:
it never records the fix on an incident and never sets a VEX status by itself. A person does that.

## Connect an issue tracker

Go to **Settings → Issue trackers**. Each connection points at one place: an Azure DevOps project with a work item type, a
Jira project with an issue type, or a GitHub repository. Connect as many as you need.

<Tabs>
  <Tab title="Azure DevOps">
    <Steps>
      <Step title="Create a personal access token">
        In Azure DevOps, go to **User settings → Personal access tokens** and create a token for this organization only,
        with the scope **Work Items (Read & write)**. Note its expiry date: a year at most.
      </Step>

      <Step title="Add the connection">
        In Pharus, select **Connect Azure DevOps**. Fill in a **Name**, the **Organization** (the name in
        `dev.azure.com/<organization>`, or paste the URL), the **Project**, the **Work item type** (for example Bug, Issue
        or Task), the **Personal access token** and when the **Token expires on**.
      </Step>

      <Step title="Save">
        Pharus checks the organization, project and type with the token before it saves. It stores the token encrypted
        and doesn't show it again.
      </Step>
    </Steps>

    Owners and admins get an email 14 days before the token expires, and the connection shows "Token expires" with the
    date. Select **New token** on the connection to replace it.
  </Tab>

  <Tab title="Jira">
    <Steps>
      <Step title="Give consent">
        Select **Connect Jira**. Atlassian asks you to let Pharus read and write Jira work items. Accept.
      </Step>

      <Step title="Finish the setup">
        Back in Pharus, the connection shows "Setup not finished". In **Finish connecting Jira**, choose the **Site**, find
        and choose the **Project**, the **Issue type** (Bug when the project has it) and a **Name**.
      </Step>
    </Steps>

    Pharus refuses an issue type that requires fields it can't fill. If Jira stops accepting Pharus, select
    **Reconnect**.
  </Tab>

  <Tab title="GitHub">
    <Steps>
      <Step title="Authorize">
        Select **Connect GitHub** and sign in to GitHub. Pharus lists the repositories you can see where the Pharus app is
        installed. If there are none, GitHub asks you to install the app first.
      </Step>

      <Step title="Choose the repository">
        In **Finish connecting GitHub**, choose the **Repository** and a **Name**. If a repository is missing, follow
        **Repository missing? Add it to the Pharus app on GitHub**.
      </Step>
    </Steps>

    Only private and internal repositories can be chosen: an issue in a public one would publish the vulnerability
    before its fix. Archived repositories and repositories with issues turned off aren't offered either. The Pharus app
    can write issues and read metadata on the repository, nothing else.
  </Tab>
</Tabs>

Each connection shows whether it is **Connected**, **Needs attention** or **Setup not finished**, when Pharus last read
it and how many tickets it has. Use **Rename** or **Remove** to manage it. Removing a connection stops Pharus reading its
tickets; they stay on their incidents and findings with what Pharus last read.

A setup that is never finished is removed after 24 hours.

### Open a ticket for every new incident

Turn on **Open a ticket for each incident Pharus opens** on one connection to have Pharus open a ticket by itself for
every incident it opens from an exploited match. It never does this for incidents you declare, incidents from disclosure
reports or drills. Only one connection at a time can have it on.

## Open a ticket

<Steps>
  <Step title="Find the ticket card">
    On an incident's Overview tab, find **Remediation ticket**. For a finding, open the vulnerability under
    **Vulnerabilities** and find **Ticket** on the finding's row in **Affected in your products**. A finding gets a ticket
    while its VEX status is **Affected** or **Investigating**.
  </Step>

  <Step title="Describe it">
    Select **Open ticket**. Choose the **Tracker**, check the **Title** and add a **Note (optional)** for the engineers,
    up to 2 000 characters.
  </Step>

  <Step title="Check what Pharus sends">
    **What Pharus sends** shows the ticket exactly as it will appear in the tracker.
  </Step>

  <Step title="Open it">
    Select **Open ticket**. The card then shows the ticket's key, linked to the tracker.
  </Step>
</Steps>

Each incident and each finding has one ticket. When Pharus opens an incident about a finding that already has a ticket,
the incident takes the ticket over.

To follow a ticket that already exists, select **Link existing** and give the work item number, issue key or issue
number, or paste its link. The ticket must be in the connection's own project or repository. Pharus reads it and doesn't
change it.

## What the ticket contains

* **Title**: `[Pharus INC-0042]` and the incident's title, or `[Pharus]`, the vulnerability, the component and the
  family for a finding. You can edit it.
* **Facts**: the vulnerability when its id is public, the severity, whether it is exploited (CISA KEV, ENISA EUVD), the
  component, its package URL, the product and the versions without the fix. For an incident, also when awareness
  started.
* **Your note**, if you wrote one.
* **What to do**: that the CRA asks for remediation without delay, and what to record in Pharus once it is fixed.
* A link back to Pharus, and the labels `pharus` and `security`.

Never the incident's summary, a disclosure report, a reporter's details, decisions or anyone's name. GitHub issues
mention nobody and refer to no other issue.

## Follow the ticket

Pharus reads every ticket every 15 minutes, and tickets closed in the last 30 days too, so a reopened ticket shows.
Select **Refresh** on the card to read it now.

The card shows the tracker's own state, mapped to Open, In progress, Done or "Closed without a fix", whether it is
assigned (not to whom), its resolution and when it was closed. State changes appear on the incident's timeline and in the
[audit trail](/reports/audit-trail).

When the ticket is done:

* **On an incident**, Pharus says that the ticket was closed and reminds you to record the fix once users can get it.
  Recording the fix starts the final report's clock. See [reporting clocks](/incidents/clocks).
* **On a finding**, select **Set VEX: fixed**. The VEX dialog opens with "Fixed:", the ticket's key and the date. Check
  it and save.

To stop following a ticket, select **Unlink**. The ticket stays in your tracker, and its history stays in the audit trail.

## When a connection needs attention

If the tracker refuses the token, or the project, type or repository is gone, the connection shows **Needs attention**.
Owners and admins get one email, and Pharus stops reading its tickets and opening new ones until it is fixed:

* **Azure DevOps**: select **New token** and paste a new personal access token.
* **Jira**: select **Reconnect**.
* **GitHub**: select **Reconnect**. If the Pharus app was removed from the repository, an owner of the GitHub
  organization adds it back first.

If a GitHub repository turns public, Pharus refuses to open new tickets in it.

## After a move to Starter

Starter has no issue trackers. Existing connections keep syncing, and owners and admins can still rename, reconnect and
remove them, so you can wind them down. Opening and linking new tickets needs Core or Plus again. While the workspace is
read-only, Pharus doesn't read tickets.

## Related

<CardGroup cols={2}>
  <Card title="Incidents" icon="siren" href="/incidents/overview" />

  <Card title="Vulnerabilities" icon="bug" href="/monitoring/vulnerabilities" />

  <Card title="Reporting clocks" icon="alarm-clock" href="/incidents/clocks" />

  <Card title="Members and roles" icon="users" href="/workspace/members-and-roles" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.