[ Applies to ] StorageGuard 10.1 and later / All supported storage, backup, SAN and cloud systems / Windows and Linux deployments
A vulnerability finding carries more decision data than a configuration finding: how exploitable it is, whether attackers are using it, what version fixes it, and what the impact is on confidentiality, integrity and availability. This article explains those fields and how to turn them into a patching order.
In this article
Before you begin
- You've read how configuration findings work; vulnerability findings share the same lifecycle and most actions. See Review and act on a configuration finding.
Find the finding
Go to Vulnerabilities > Risks. The page works like the Baseline Configuration Risks page: filter and group on the left, open a finding to see its details. The vulnerability-specific fields below are available as columns and filters.
Read the vulnerability fields
| Field | What it tells you |
|---|---|
| Vulnerable version | The version of the software, operating system or firmware installed on the system. |
| Remediating version | The version or patch that fixes the issue. This is your target. |
| Link | The vendor's published advisory. |
| CVSS Score | The highest CVSS severity score among the CVEs in the advisory. |
| Exploit Subscore | The highest exploitability subscore among those CVEs: how easy the vulnerability is to exploit. |
| Known Exploits | Whether any of the CVEs has a known exploit. |
| Exploit POC | Whether a proof-of-concept exploit has been published. |
| In CISA | Whether a CVE is in CISA's Known Exploited Vulnerabilities (KEV) catalog, meaning it's being actively exploited. Also shown as an icon. |
| CVE Labels | Every CVE identifier the advisory covers. |
| References | Articles about the advisory, known exploits, proof-of-concept code and related material. |
| Workaround | Mitigations you can apply if you can't patch yet. |
| CIA impact | Three fields, Confidentiality, Integrity and Availability, each with the impact level. |
| Advisory publication date | When the vendor published the advisory. |
| Resolution publication date | When the vendor published the fix. |
| Closure Reason | Why a closed finding closed: a software update, the system was decommissioned, and so on. |
Decide what to fix first
CVSS alone ranks vulnerabilities by theoretical severity. Combine it with what's happening in the wild and what the system does:
- In CISA KEV, or Known Exploits: patch first. These are being exploited now.
- Exploit POC published: next. An exploit is a short step away.
- Critical or high CVSS, with a high Exploit Subscore: then these, starting with systems whose CI role rates them most important.
- Everything else: schedule it into normal patch cycles. Where a Workaround exists, apply it in the meantime.
Tip: Sort the Risks page by In CISA, then Known Exploits, then CVSS Score, and work from the top. Group by Remediating version to see how many findings one upgrade closes.
Act on the finding
Set priority, assignee and due date, mark the finding complete when the system is patched, or suppress it when the risk is accepted, exactly as for a configuration finding. See Triage and Mark it complete. To send the finding to the team that patches the system, see Email a finding.
The Vulnerability Status report exports every open vulnerability with all of these fields to Excel, for tracking patch work outside StorageGuard.
[ Next step ]
Before an upgrade, check the target version against known CVEs.
Related articles
- Read the Vulnerabilities overview
- Check a system version against known CVEs
- Review and act on a configuration finding
[ Still need help? ]
Our support team can help with vulnerability management. Submit a request
Comments
0 comments
Please sign in to leave a comment.