Vulnerabilities (CVEs)

Pulse matches published CVEs (Common Vulnerabilities and Exposures) against your device inventory and surfaces each match as a finding you can triage. Unlike an incident — which represents a monitor going up or down — a vulnerability rarely resolves on its own. It needs a decision: does it apply to this device, is the device used in a way that exposes it, and how will you handle it? Vulnerabilities are therefore a first-class area in Pulse with their own lifecycle, activity log, and reporting, separate from incidents.

CVE monitors

A CVE monitor represents one device in your inventory that you want scanned for known vulnerabilities. You create it with the device's identity:

• Vendor — the device manufacturer (for example, Siemens).
• Order code — the manufacturer's order number (the Siemens MLFB, for example 6ES7515-2AN03-0AB0). The most precise key: an advisory that names this exact part matches.
• Product name — the product or module type as the vendor's advisories spell it (for example SIMATIC S7-1500 CPU 1518-4 PN/DP, or AC500 V3). This is how advisories that name a product rather than an order number are matched — every vendor other than Siemens, and Siemens' own software products and product families.
• Firmware (optional) — the installed firmware version, so version-specific advisories can be evaluated precisely.

A monitor needs an order code or a product name; with both, advisories naming either are matched. Vendor and product name are compared after normalizing case, spelling variants and company suffixes, so PHOENIX CONTACT and Phoenix Contact GmbH & Co. KG are the same vendor — but the product name has to be the exact product: AC500 V2 and AC500 V3 are different products with different affected versions.

CVE monitors live alongside your other monitors under CVE Monitors. You can create one there, or start one for a module from its station's page in the asset register.

Pulse re-scans each CVE monitor regularly against the vulnerability catalog. A monitor is shown as unhealthy while it has any finding that is Open or In progress, and healthy once every finding has a decision or no vulnerabilities apply.

Taking the device from the asset register

If your organization uses the asset register, a CVE monitor can take its order code and firmware from a module the register holds instead of from what you type. On the CVE monitor form, choose the asset under Asset from the register, then the Module. The order code and firmware fill in and are shown read-only, marked as coming from the register.

From then on they follow the module. When a later network scan finds new firmware on it, the monitor is matched against the new version at its next scan, without you editing it. A firmware update that removes a vulnerability shows on the station's page as Fixed by a firmware change.

• Vendor stays a value you confirm. The register records no manufacturer, so when you pick a module the form fills in Siemens if the vendor is still empty. Correct it if needed. Advisories are matched on the vendor too.
• Product name is not taken from the register. Enter it if you want product-name matching as well.
• A module without an order code cannot back a monitor. The form says so, and you enter the device by hand instead.
• To go back to typing the device, choose None (enter the device by hand).

The station picker is shown to organization administrators when your license includes the asset register. Devices the register does not hold, such as OPC UA servers or gateways, are entered by hand as before.

Findings and their lifecycle

Each applicable CVE becomes a finding attached to its CVE monitor. A finding carries the advisory details (CVSS score and severity, affected product and version, remediation guidance, and a link to the source advisory) plus a triage status:

• Open — newly detected, not yet triaged.
• In progress — actively being investigated or remediated.
• Resolved — the vulnerability has been remediated.
• Won't fix — a real vulnerability, but a deliberate decision not to remediate (accepted risk). Requires a reason.
• Not affected — triaged as not applicable (for example, the affected feature isn't used, or the version match was a false positive). Requires a reason.
• Risk accepted — temporarily accepted until a date you choose. When that date passes, the finding automatically returns to Open for re-triage. Requires a reason and a future expiry date.
• Mitigated — the vulnerability applies, but a compensating control blocks it, for example a closed port, a firewall rule, or a segmented VLAN. Requires a reason: name the control. It has no expiry date.

Only Open and In progress count against the monitor's health. Every other status is a decision and leaves the monitor healthy.

The decision statuses differ in what they say about the vulnerability:

Status	Does it apply to the device?	What stands between it and an attacker	Ends on its own?
Not affected	No	Nothing needed	No
Resolved	No longer	It was remediated, for example by a firmware update	No
Mitigated	Yes	A control you put in place	No
Risk accepted	Yes	Nothing — you accept the risk for a limited time	Yes, on the date
Won't fix	Yes	Nothing — you deliberately leave it	No

Triage decisions are sticky: they persist across re-scans. If a vulnerability disappears from a scan and later reappears, its previous triage decision is kept rather than reset.

Decisions recorded on the module

When a CVE monitor takes its device from the asset register, the triage decision is recorded on the module and the CVE, not on the monitor. The module outlives any monitor, so the decision does too:

• A second monitor on the same module shows the same decision. Changing the status on one monitor's finding changes it on the other's.
• Deleting a monitor and creating a new one brings the decision back. When the new monitor finds the CVE again, the finding starts at the recorded decision instead of Open.
• The history stays with the module, including when two stations of the register are merged or a merge is undone.

Single triage, bulk triage, and the automatic expiry of a risk acceptance are all recorded this way. The station's page shows each decision with its history; see Vulnerabilities on the station page. Monitors whose device you typed by hand keep their decisions on the monitor, as before.

To hand these decisions over, for example to an auditor, export them from the Assets page: one row per module and CVE, open or closed, with the decision in force and who made it. See Exporting the vulnerability status.

Findings are never deleted. When a re-scan no longer detects a CVE, the finding is marked no longer detected and retained, so your history and trends stay complete. Use the Show no-longer-detected filter to include these in the list.

Triaging a finding

Open a finding to see its full advisory, triage panel, and affected-devices list.

The Affected devices panel lists every device in your organization that has a finding for the same CVE — not just the one you are looking at. Each entry shows the device name, its triage status, and whether the CVE is still detected. Click any device to jump to its own finding. The current device is labeled (this device) and is not a link. Use this panel to understand the blast radius of a CVE across your fleet and to triage consistently.

Administrators can change the triage status from the Change triage action:

1. Choose the new status.
2. For Won't fix, Not affected, Risk accepted, or Mitigated, enter a reason. For Mitigated, name the compensating control.
3. For Risk accepted, pick the date the acceptance expires.
4. Save.

The same dialog opens from Record decision on a station's page in the asset register, and a decision recorded there shows on the CVE pages straight away.

Every member can add comments to a finding to record investigation notes.

Activity feed

Each finding keeps a chronological activity feed of everything that happened to it — automatic scan events (detected, no longer detected, reappeared, risk-acceptance expired) and human actions (triage changes with the before/after status and reason, and comments). Scan-driven entries are attributed to System; human entries show who made them.

The Activity tab on the Vulnerabilities page shows the same events across every finding in your organization, newest first, so you can see recent triage and detection activity at a glance.

The Vulnerabilities page

The Vulnerabilities page has four tabs:

• Overview — a summary dashboard with counts by triage status and severity, a 30-day detected-vs-resolved trend, and the most affected devices.
• CVEs — one expandable row per unique CVE, aggregated across all your devices. Each row shows the CVE id, title, how many devices are affected, the severity, and a breakdown of triage statuses across all findings of that CVE. Click a row to expand it and see the individual findings inline.
• Findings — one row per individual finding (a flat list).
• Activity — the org-wide activity feed (see Activity feed).

Filtering and searching

The CVEs and Findings tabs share the same filter and search controls:

• Search — by CVE id, title, or affected product.
• Filter — by triage status, severity, and monitor tags; and toggle whether no-longer-detected findings are shown.

Bulk triage

From the CVEs view, organization administrators can triage all findings of a CVE at once without opening each one individually. Click the ⋯ menu on a CVE row and choose Triage all. The dialog works the same as the single-finding triage dialog — choose a status, add a reason if required, and confirm. The decision is applied to every finding of that CVE across your organization's devices.

If filters are active when you open the bulk triage dialog, a notice reminds you that the action applies org-wide, not only to the filtered subset visible in the current list.

Bulk triage events appear in the activity feed with the label Bulk-triaged, so you can distinguish them from single-finding triage changes.

Investigating with AI Canvas

On any CVE finding detail page, the Ask AI button opens the AI Canvas with a pre-filled question about that specific CVE and device. The assistant explains the vulnerability in plain terms — what it is, how severe it is, and what an attacker could do — and then analyzes how it affects the particular monitored device: whether it is likely exploitable in an OT environment and what concrete remediation or mitigation steps to take.

You can also ask the AI Canvas about vulnerabilities without opening a specific finding. From the canvas, the assistant can query your CVE findings by triage status, severity, affected device, and other filters — for example, "which of my devices have critical open CVEs?" or "give me a vulnerability report for my Siemens devices."

Reporting

Pulse emails a weekly vulnerability summary to organization administrators: counts by triage status plus the number of new critical and high-severity findings detected in the past week. No configuration is required.

Licensing

The vulnerability feature is enabled per organization by your license. Without it, CVE monitors and findings are unavailable.