> ## 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. # Vulnerabilities > How Pharus matches your SBOMs against OSV.dev, CISA KEV and ENISA EUVD, when a match opens an incident, and how to record a VEX status. **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 | Source | What Pharus uses it for | | - | - | | OSV.dev | Which known vulnerabilities affect a package version, with the summary, severity, aliases and references | | CISA KEV | The Known Exploited Vulnerabilities catalog: a vulnerability listed there counts as exploited | | ENISA EUVD | The EU Vulnerability Database: an entry marked as exploited counts as exploited | 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. | Match | How | When | | - | - | - | | Exact · purl | Pharus asks OSV.dev which vulnerabilities affect the package at that version | The component has a purl of a type OSV.dev covers, such as `npm`, `pypi`, `maven`, `golang`, `cargo`, `nuget`, `deb` or `apk` | | Name only | Pharus compares the product name, and the vendor where both sides name one, with the entries in CISA KEV and the exploited entries in EUVD | The component has no such purl: CPE only, `generic`, `conan`, `rpm` and others | 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](/monitoring/sboms#get-exact-matches) 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](/incidents/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](/notifications/overview). 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 On **Vulnerabilities**, select the CVE. A possible match shows the box "Possible match — version not verified". Compare the component's version with the affected versions in the summary and references. 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. | Column | What it shows | | - | - | | **CVE** | The vulnerability; select it to open its page | | **Component** | The component and version, and the product family | | **Source** | CISA KEV, EUVD, "Not affected · VEX", or the severity when the match isn't exploited | | **VEX** | The VEX status, which you can change here | | **Incident** | The linked incident, if there is one | | **First seen** | When Pharus first found the match | 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**. | Status | Use it when | | - | - | | Affected | The product is affected | | Investigating | You haven't decided yet | | Not affected | The product isn't affected. Needs a justification. | | Fixed | A fix is out | 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. 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](/reports/audit-trail), linked to the incident when there is one. The VEX statuses feed the product status in your [CSAF advisories](/disclosure/advisories). To change the justification or detail later, use **Edit VEX statement** on the vulnerability's page. ## Search 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. ## Related This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.