Vulnerabilities
A vulnerability is a weakness in a system, a process or a product that could be exploited. The register tracks them as first-class objects, separate from the incidents they might cause and the risk scenarios they feed. It answers two operational questions: what is exposed, and are we fixing it fast enough.
Where to find it
Section titled “Where to find it”Risk → Vulnerabilities in the sidebar.
Key concepts
Section titled “Key concepts”Identification and severity
Section titled “Identification and severity”Each entry carries a Name, a Description and a Reference ID — typically the CVE identifier, which is what makes the record recognisable to everyone else in the conversation. Severity uses the shared scale: undefined, info, low, medium, high, critical.
Status
Section titled “Status”| Status | Meaning |
|---|---|
| Undefined | Not yet triaged |
| Potential | Suspected but unconfirmed in your environment |
| Exploitable | Confirmed and reachable |
| Mitigated | Risk reduced by a compensating control |
| Fixed | Remediated at the source |
| Not exploitable | Present, but not reachable as deployed |
| Unaffected | Your configuration is not subject to it |
The last two matter as much as the first: recording why something is not a problem is what stops it being re-triaged every quarter.
What a vulnerability links to
Section titled “What a vulnerability links to”- Assets — what is exposed.
- Applied controls — the patches, configuration changes and compensating measures treating it.
- Exceptions — the approved deviation, when it cannot be fixed inside the SLA.
- Security advisories and CWEs — the intelligence behind the record.
- Labels — your own tags for grouping by system, team or campaign.
Findings and risk scenarios can point at a vulnerability too, so the same weakness connects a pentest result, a risk score and a remediation task.
SLA-driven due dates
Section titled “SLA-driven due dates”Vulnerabilities are unusual in that CyberGuard sets the Due date for you. The Vulnerability SLA policy in settings maps each severity to a maximum number of days to remediate, anchored on either the Detection date or the Publication date. When a vulnerability is created, or its severity changes, and no due date has been set explicitly, the policy fills one in. The Detection date defaults to today on creation.
Explicit due dates you or an import set are preserved — the policy only fills blanks. The one exception is the Refresh SLA due dates action on the list, which recalculates every due date from the current policy and overwrites what is there; use it after changing the SLA configuration.
Working with the register
Section titled “Working with the register”The list supports search and filters by severity, status, domain, label and applied control. Use Add vulnerability for one-off entries, or the data import wizard for a scanner export.
Treemap view
Section titled “Treemap view”The Visualize button opens the vulnerability treemap: a hierarchical view of Domains → Severity → Status, sized by count. Click a block to drill down, and use the severity and status filters above the chart to narrow what is plotted. It is the fastest way to see whether a domain’s exposure is concentrated in a few critical items or spread thinly, and how much of it is already mitigated.
Related
Section titled “Related”- Applied controls — the remediation work itself.
- Exceptions — sanctioning a vulnerability you cannot fix in time.
- Assets — what a vulnerability exposes.
- Risk scenarios and Findings tracking — where vulnerabilities feed analysis and remediation.
- Settings — configuring the vulnerability SLA policy.