Skip to main content
This page explains the words Pharus uses and how the pieces fit together. Each section links to the page that covers it in depth. Short definitions of the regulatory terms are in the glossary.

​
Workspace and members

A workspace is one company in Pharus. The app calls it a company: you switch between your companies in the sidebar, and Settings → Company holds its details. Every record in Pharus belongs to exactly one workspace, and nothing is shared between them. One person can be a member of several workspaces. Each member has one role: owner, admin or member. Owners handle billing and can close the workspace; owners and admins manage settings, people and the decisions that need a second level of authority; every member can do the day-to-day work. See members and roles.

​
Product family

A product family is a group of products that share their software, such as a gateway sold in three hardware variants with the same firmware. SBOMs, API tokens, support periods and the Annex VII technical documentation belong to a product family. Plans are priced and limited per family. See product families.

​
SBOMs, components and matches

An SBOM (software bill of materials) lists the components in a build of your product. Pharus reads CycloneDX and SPDX SBOMs in JSON, from your pipeline, from Dependency-Track or from an upload. Each component is identified by its purl (package URL). Pharus matches every component against OSV.dev. A match says that a known vulnerability affects a component in one of your product families. Pharus also checks each vulnerability against CISA’s Known Exploited Vulnerabilities catalog (KEV) and ENISA’s EU Vulnerability Database (EUVD): a match on a vulnerability known to be exploited is the one that can start the CRA clock. For each match you record a VEX status: affected, not affected (with a justification), fixed, or under investigation. VEX statuses feed your advisories. See vulnerabilities.

​
Incident

An incident is one reportable event, with a reference such as INC-0042. Article 14 of the CRA knows two kinds:
  • An actively exploited vulnerability in your product (Art. 14(1)).
  • A severe incident that affects the security of your product, such as a compromised build or update server (Art. 14(3)).
A new exact match on an exploited vulnerability opens an incident by itself. You can also declare one by hand, or from a report in the disclosure inbox. See incidents.

​
Awareness and clocks

The awareness time is when you became aware of the incident. For an incident Pharus opened from a match, it is the time Pharus first saw the match as exploited. Every CRA deadline counts from it, so it is recorded once and corrected only by an owner or admin, with a reason, in the audit trail. The clocks are the CRA deadlines that run from awareness: See clocks.

​
Determination and decision record

The determination is your company’s answer to the question an incident turns on: is it reportable under CRA Art. 14? For a vulnerability, was it actively exploited in your product; for an incident, is it severe? On Core and Plus, the decision record keeps the rationale, the evidence and the approvals for each answer on the incident’s Determination tab, in entries that can’t be changed afterwards. The awareness time is kept apart from it, on the incident’s Overview tab. See decision record.

​
Routing, the SRP and CSIRTs

CRA reports go through ENISA’s Single Reporting Platform (SRP) to a coordinating CSIRT: the computer security incident response team of one EU member state. Article 14(7) decides which one: the member state of your main establishment in the EU, if you have one. Otherwise the first link in a cascade that is in an EU member state: your authorised representative, then your importer, then your distributor, then the member state with the most users. The CRA is not yet part of the EEA Agreement, so a Norwegian manufacturer follows the cascade too. Pharus works out the route and prepares an SRP paste pack: the fields of the SRP form, in English, filled in where Pharus has the answer and ready to paste. See routing and SRP paste pack.

​
Regimes

A regime is one set of reporting rules that may apply to the same incident. Next to the CRA, Pharus assesses GDPR (Datatilsynet), digitalsikkerhetsloven (NSM) and, for financial entities, DORA (Finanstilsynet), each with its own deadlines. For a company established in Norway, NIS2 is shown as tracked: it is not yet Norwegian law. See Norwegian notices and DORA.

​
Disclosure reports and advisories

A disclosure report is a vulnerability report from someone outside your company, sent through your public disclosure page or by email. It lands in the disclosure inbox, where you reply, triage and, if needed, declare an incident from it. See disclosure page and inbox. An advisory tells your customers which of your products a vulnerability affects and what to do. Pharus publishes advisories as CSAF 2.0 documents with VEX statuses, on a public page and in a machine-readable feed. See advisories.

​
Audit trail

The audit trail logs every determination, approval, filing and setting change, with who did it and when. Entries can’t be edited or deleted. See audit trail.

Quickstart

Set up a workspace and match your first SBOM.

Glossary

Short definitions of CRA and reporting terms.