> ## Documentation Index > Fetch the complete documentation index at: https://docs.oasm.io/llms.txt > Use this file to discover all available pages before exploring further. # Vulnerability > Monitor, analyze, and manage detected security vulnerabilities across your attack surface The Vulnerability module provides a centralized interface to monitor, analyze, and manage all detected security findings across your assets. It aggregates results from scanning tools and presents them in a structured way, allowing you to quickly identify risk, investigate details, and take action — from triage to dismissal or escalation into an [issue](/issue). You can reach the module from the console sidebar by opening **Vulnerabilities** (under the **Security** section). *** ## Overview The vulnerabilities page gives you a single, filterable view of every finding currently tracked in your workspace. The page is composed of three parts: * **Filter buttons** — quickly narrow the list by resolution state, severity, date, tags, or target * **Table** — one row per vulnerability with the fields described below * **Pagination** — browse the list when the number of findings grows ### Filter buttons At the top of the list you can filter by: * **Open** — show only vulnerabilities that have not been dismissed * **Severity** — narrow by risk level * **Date** — limit to findings first or last seen within a time range * **Tags** — filter by technical category (for example SSL, TLS, or DNS) * **Target** — scope the list to a single target's findings ### Table columns Each row in the vulnerability table contains: | Column | Description | | - | - | | **Severity** | Risk level of the finding — Critical, High, Medium, Low, or Informational | | **Details** | Name of the vulnerability or detection, e.g. **SSL Certificate Expiry** | | **Asset** | The asset the finding is attached to | | **Tags** | Technical categories associated with the finding | | **First Seen** | When the finding was first detected | | **Last Seen** | When the finding was most recently observed | | **Scanned by** | The scanning tool that found it, shown as a badge | | **Status** | Current state of the finding | | **Analyze** | Per-row action that triggers AI analysis of the finding | The **Scanned by** column identifies the tool that generated the finding. Because every finding originates from a scan, you can trace it back to the [job](/jobs) that discovered it. *** ## Severity levels Each vulnerability is ranked by its severity. Use the table below to decide how urgently to respond: | Severity | Criteria (indicative) | Recommended action | | - | - | - | | **Critical** | Trivially exploitable; remote code execution or equivalent impact | Fix immediately; treat as incident | | **High** | Easily exploitable; significant confidentiality, integrity, or availability impact | Fix urgently, within days | | **Medium** | Exploitable with effort; limited data or access exposure | Prioritize and fix in a planned window | | **Low** | Limited impact, hard to exploit, or requires unusual conditions | Schedule a fix in the normal cycle | | **Informational** | Non-exploitable observations, version banners, informational detections | Review during low-priority triage; dismiss if not applicable | Severity is the primary signal for prioritization. Combine it with the asset's role — a High finding on an internet-facing service usually outranks a Critical one on an internal-only host. *** ## Vulnerability lifecycle A vulnerability moves through a lifecycle from raw detection to resolution: **1. Discovered** A scan — triggered from a [target](/target) or [group](/group) — detects the finding. The vulnerability appears in the list with severity, tags, and asset information. The **Scanned by** column records which scanner produced it. **2. Analyzed** Use the **Analyze** action to generate an AI-assisted analysis report, or review the scanner description manually. Analysis turns raw scanner output into context you can act on (see [AI analysis](#ai-analysis)). **3. Triaged as issue** For actionable findings, escalate the vulnerability into an [issue](/issue) — a tracked follow-up item used to track, comment on, and close out work. The issue stays linked to its vulnerability source. **4. Dismissed or fixed** If the finding is a false positive, was part of a test, or will not be fixed, dismiss it with a reason. Otherwise apply the remediation and let a re-scan confirm the fix. **5. Closed** Once fixed, the finding stops being re-reported and leaves the active triage flow. Dismissed findings stay available with their dismissal reason for audit. *** ## AI analysis The **Analyze** button on each row (and in the detail page) runs an AI-assisted analysis of the finding. The system uses the scanner output and the surrounding asset context to produce a structured report that includes a **Risk Summary** and concrete **remediation** guidance, with **Copy** buttons to copy the report or sections. AI analysis can be Not started, Running, Done, or Failed. While analysis is running, the section shows its progress. When it finishes, the generated report is displayed, including the risk summary and remediation steps you can copy into your ticketing or workflow tooling. *** ## View vulnerability details Click a vulnerability's **Details** value (for example **SSL Certificate Expiry**) to open its detail page. The page shows the scanner that produced the finding and recency information in the format **discovered X days ago • updated Y days ago**. ### General * **Scanner** — the tool that detected the finding (shown as a badge) * **Description** — explanation of the issue and its security implications (for example, the scanning tool's own description) * **Dismiss alert** — dismiss the finding with a reason (see below) ### Network & Metrics * **Affected URL** — the full address where the finding applies, including the port when relevant * **Asset** — the associated asset * **Ports** — ports related to the finding, e.g. port 443 serving HTTPS > [!NOTE] > > Vulnerabilities are automatically generated from scans executed via configured tools and schedules in [targets](/target) or [groups](/group). You cannot create them manually. *** ## Dismiss a vulnerability Not every finding requires remediation. Use **Dismiss alert** on the detail page when a finding is not applicable, then choose the reason: * **False positive** — the detection is incorrect; the condition does not exist * **Used in a test** — the finding was intentionally created as part of a security test * **Won't fix** — the finding is real but the team has accepted the risk or will not remediate Dismissed vulnerabilities are hidden from the default **Open** filter but remain available for auditing. A dismissal can be revisited if the situation changes. *** ## Triage into issues For findings that need tracked, actionable follow-up, escalate them into the [issue](/issue) module. An issue acts as a tracked follow-up item on top of the raw vulnerability: an issue is either Open or Closed, supports comments for collaboration, and remains linked to the vulnerability it came from. *** ## Related pages > **[Issues](/issue)** > > Track, comment on, and close findings triaged from vulnerabilities. > **[Jobs](/jobs)** > > Every vulnerability is produced by a scan job; trace findings back to their source. > **[Notifications & integrations](/integrations/overview)** > > Receive alerts about new findings via Slack, Telegram, or other channels. > **[Search](/search)** > > Find vulnerabilities and assets across the workspace. *** ## API Everything available in the console is also available through the API — see the API Reference tab. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.