Vulnerability Management
Vulnerability Management is where your scan results come to be triaged, prioritized, and tracked to closed. Every finding from across the platform — cloud misconfigurations, container and Kubernetes issues, web app vulnerabilities, and code findings — is normalized into a single, consistent view so your team works from one queue instead of jumping between tools.
The single pane of glass
The Vulnerability Dashboard is the platform's single pane of glass — the surface where the unified security data layer becomes one actionable list. It shows every finding from every source, not just the platform's own scanners:
- Native modules — Cloud Security, application/API/network scanning, SAST and code, SBOM/license, container and Kubernetes, and on-prem OpenVAS.
- On-prem telemetry — host and endpoint findings from the Wazuh integration.
- Integrated third-party products — when you connect an external scanner or security product, its findings are captured into this dashboard too. Results from tools such as Qualys, Tenable, Rapid7, Snyk, SonarQube, Checkmarx, Veracode, GitHub CodeQL, and AWS Security Hub flow into the same data layer and appear here, deduplicated against native findings — so you don't log into each console to assemble the picture. See Integrations.
Because everything lands in one normalized model, you get one severity scale, one asset identity, and one deduplicated queue across the platform's own scanning and the tools you already run.
Consolidating onto Offload Security doesn't mean giving up the scanners you trust. Their output is ingested and unified here, so the Vulnerability Dashboard is a complete view of exposure — not a link farm to other dashboards.
What it does
The platform turns raw scanner output into occurrences — a single occurrence is one specific vulnerability found on one specific asset. Each occurrence is enriched with threat intelligence, scored for risk, assigned an SLA due date, and moved through a defined lifecycle until it's resolved and verified.
Key capabilities:
- Unified findings from many scanners (cloud, container, Kubernetes, web, and code) in one list, each tagged with the scanner that found it.
- Risk-based prioritization using CVSS severity, real-world exploitation signals (EPSS and CISA KEV), and a clear P0–P4 priority rank.
- Occurrence de-duplication, so the same issue seen on every scan run isn't counted twice — it's tracked as one finding with a count of affected assets.
- SLA tracking with per-finding due dates and clear breach warnings.
- Ownership and lifecycle — assign a finding to a person and walk it through triage, remediation, and verification.
- Built-in remediation guidance on every finding.
How findings are prioritized
Not every finding deserves the same urgency. The platform combines several signals so the most exploitable, highest-impact issues rise to the top:
| Signal | What it tells you |
|---|---|
| Severity (CVSS) | Technical severity on a 0–10 scale, grouped as Critical (≥9.0), High (≥7.0), Medium (≥4.0), and Low (≥0.1). |
| EPSS | The Exploit Prediction Scoring System — a probability (0–1) that the vulnerability will actually be exploited in the wild. |
| CISA KEV | Whether the vulnerability is in CISA's Known Exploited Vulnerabilities catalog. KEV findings are confirmed to be exploited and are prioritized accordingly. |
| Risk Score & Priority Rank | The platform rolls the above into a single risk score and a priority rank from P0 (most urgent) to P4, so you can sort and filter by what matters most. |
A "Medium" CVSS finding that's in the KEV catalog or has a high EPSS score is often more urgent than an untouched "Critical." Sort by priority rank to let the combined signal guide your day.
How to use it
1. Open the queue and filter
Go to Vulnerability Management to see all occurrences for your active team. Use the filters at the top to focus your list:
- Status — show only
Open,Triaged,In Progress,Resolved, and so on. - Minimum Severity (CVSS) — Critical, High, Medium, or Low and above.
- Priority Rank — P0 through P4.
Select Clear Filters to reset. The table shows each occurrence's ID, affected asset, severity, priority, status, the scanner that found it, and its SLA Due date. Findings that have missed their SLA are highlighted and flagged as breached.
2. Review a finding
Select View Details on any row to open the full finding, which includes:
- Basic information — the occurrence and vulnerability IDs, the affected asset, and the source scanner.
- Risk assessment — the CVSS score, the computed risk score, and the priority rank.
- Remediation — a recommended fix, step-by-step instructions where available, plus the expected complexity and estimated effort.
3. Assign an owner
In the detail view, enter a teammate's email under Assign Occurrence and select Assign. The finding now has a clear owner, which also drives SLA acknowledgment tracking.
4. Move it through the lifecycle
Update Status as work progresses and add an optional comment to record context for auditors and teammates. Findings flow through these states:
| Status | Meaning |
|---|---|
| Open | Newly ingested, not yet reviewed. |
| Triaged | Reviewed and confirmed as something to act on. |
| In Progress | Remediation has started. |
| Resolved | The owner believes the issue is fixed. |
| Verified | A follow-up scan confirmed the fix. |
| Closed | Finished and filed. |
| False Positive / Accepted Risk | Alternative outcomes when a finding isn't valid, or the risk is formally accepted. |
The same vulnerability detected on every scan run is not logged as a new finding each time — the platform recognizes it and keeps a single occurrence, tracking how many assets it affects. This keeps your queue honest and your counts stable over time.
SLAs and due dates
When a finding is ingested, the platform matches it to your SLA policy (based on severity, environment, and asset criticality) and stamps it with a due date. The SLA Due column shows that deadline, breached findings are highlighted in the list, and your team can be notified as deadlines approach or pass. To define or adjust the timelines that drive these due dates, see SLA Management & Breach Monitoring.
Exporting and pulling findings
- Reports — produce executive, compliance, and audit-ready exports (PDF, HTML, and Excel) from Security Reports, with vulnerability findings included.
- API access for CI/CD — your pipeline can query the occurrence list programmatically (using an API key) to gate builds on open or high-priority findings. See CLI & CI/CD integration.
Prerequisites
Viewing findings requires the vulnerability view permission; changing status, assigning owners, and ingesting scans require vulnerability management. Roles are managed in Team Management.
You only see occurrences for your active team. If your queue looks empty or unfamiliar, confirm you're in the right team using the account menu in the top-right before triaging.
Related
- Vulnerability & Risk Management overview — how findings flow into risk and governance.
- SLA Management & Breach Monitoring — define remediation timelines and track breaches.
- Risk Register & GRC — promote significant findings into managed business risks.
- CLI & CI/CD integration — query findings from your pipeline and gate builds.
Frequently asked questions
How should security teams deduplicate vulnerability findings?
Offload normalizes findings from every source into a shared model and reconciles duplicates automatically, so the same issue reported by different scanners collapses into a single tracked finding in one queue.
How does Offload Security prioritize vulnerabilities?
Findings are risk-scored using exploit and threat signals such as EPSS and CISA KEV together with asset and business context, so teams focus on what is genuinely exploitable and important rather than raw CVSS alone.
How do you validate vulnerability closure after a Jira ticket is resolved?
A resolved ticket is not treated as proof a vulnerability is fixed. Offload confirms closure when a subsequent scan no longer detects the finding, so remediation is verified rather than assumed.