Skip to main content
Plans: Every plan. On Free, monitoring is paused: no new matches or alerts. Who: any member sets VEX statuses and confirms possible matches.
Pharus checks every component in your active SBOMs against public vulnerability data and lists each hit as a match under Vulnerabilities. When a component you ship has a vulnerability that is known to be exploited, Pharus opens an incident and the CRA’s 24-hour clock starts.

​
Where the data comes from

A match is exploited when one of its CVE ids is in CISA KEV, or ENISA EUVD marks it as exploited.

​
How often Pharus checks

  • Every 30 minutes Pharus syncs CISA KEV and EUVD and matches every active SBOM again. The top of the Vulnerabilities page shows this, for example “KEV · EUVD · every 30 min · synced 12 min ago”.
  • Pharus asks OSV.dev about each component with a supported purl again every six hours, so a newly published OSV record can take up to six hours to show.
  • A new SBOM is matched within seconds of arriving, with the newest data.

​
How matching works

Pharus matches a component in one of two ways. The Match column on a vulnerability’s page says which. A name-only match never checks the version. It shows as “Version not verified” and needs a person to confirm it. Names shorter than three characters are never matched. The SBOMs page lists every purl type that gets exact matches. A match is one vulnerability in one component of one product family, across all of that family’s active SBOMs, with the product versions that contain the component. When the component leaves every active SBOM, the match shows as “Removed”.

​
When an incident opens by itself

Pharus opens an incident on its own when an exact match is exploited: a new match that is already exploited, or an existing match that CISA KEV or EUVD has just listed. Awareness is the time Pharus first saw the match as exploited, so the 24-hour early-warning clock starts then. See reporting clocks.
  • Pharus opens one incident per vulnerability and product family.
  • It doesn’t open one when the match’s VEX status is Not affected or Fixed.
  • It sends the alert emails and, on Core and Plus, pages whoever is on call. See notifications.
A name-only match never opens an incident by itself. It is listed in the alert email as a possible match, and a member decides.

​
Confirm a possible match

1

Open the vulnerability

On Vulnerabilities, select the CVE. A possible match shows the box “Possible match — version not verified”.
2

Check the version you ship

Compare the component’s version with the affected versions in the summary and references.
3

Confirm or dismiss

If you ship an affected version, select Confirm match, then Confirm and open incident. Awareness is the time you confirm, so the 24-hour clock starts then. If you don’t, select Mark as not affected and give a justification.

​
The Vulnerabilities list

The tabs split the matches: All, Actively exploited, Investigating and Not affected. Above the list you can pick a Product family, search by CVE, component or purl, and tick Include removed components. A link from another page can add a filter, shown as a tag you can remove. Exploited matches come first, then the newest. The list shows 50 matches per page. Matches of archived product families aren’t listed.

​
A vulnerability’s page

  • Summary: the OSV.dev description, Severity (computed from the CVSS vector, or EUVD’s base score), Vector, Published, Modified and Also known as.
  • CISA KEV, when listed: Added to KEV, Required action, Due date for US federal agencies, Known ransomware use, Vendor · product and Open in the KEV catalog.
  • EUVD, when listed: Base score, EPSS, whether it is marked as exploited and since when, and Open in EUVD.
  • Affected in your products: one row per component and product family, with Match, VEX, the product Versions and when it was Seen first and last.
  • Incidents linked to the vulnerability, References, and the History of VEX changes and confirmations.

​
Set a VEX status

A VEX status records whether a vulnerability affects your product. Every new match starts as Investigating.
1

Pick the status

In the VEX column of the list, or in Affected in your products on the vulnerability’s page, choose the new status. Affected, Investigating and Fixed save straight away.
2

Justify not affected

For Not affected, choose a Justification: Component not present, Vulnerable code not present, Vulnerable code not in execute path, Vulnerable code cannot be controlled by adversary, or Inline mitigations already exist. Add an optional Detail of up to 1 000 characters on what you checked, and how. Select Save VEX statement.
Each change is recorded in the audit trail, linked to the incident when there is one. The VEX statuses feed the product status in your CSAF advisories. To change the justification or detail later, use Edit VEX statement on the vulnerability’s page. Use the search field at the top of every page, or open Search. It finds incidents, vulnerabilities, advisories, disclosure reports, SBOM versions (active and retired), components in your active SBOMs and product families. Try a CVE id, an EUVD id, a component name or purl, an SBOM version, an advisory ID, a report number such as #118 or an incident reference such as INC-0001. An exact incident reference, advisory ID or report number, or a CVE with a single match, opens directly. Otherwise results are grouped by kind, up to 25 in each group.

SBOMs

Incidents

Reporting clocks

Weekly digest