Skip to main content
Plans: Core and Plus, and the free trial. Who: owners and admins connect issue trackers; any member opens, links and unlinks tickets.
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.
1

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.
2

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.
3

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.
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.
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

1

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.
2

Describe it

Select Open ticket. Choose the Tracker, check the Title and add a Note (optional) for the engineers, up to 2 000 characters.
3

Check what Pharus sends

What Pharus sends shows the ticket exactly as it will appear in the tracker.
4

Open it

Select Open ticket. The card then shows the ticket’s key, linked to the tracker.
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. 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.
  • 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.

Incidents

Vulnerabilities

Reporting clocks

Members and roles