Vulnerabilities

Overview

Vulnerabilities are the security weaknesses Guard discovers across your attack surface. A vulnerability represents a specific finding — a misconfiguration, an exposed credential, an unpatched CVE, a weak TLS certificate, or any other issue that an attacker could exploit — tied to the asset where it was found. The Vulnerabilities page is your central hub for triaging, tracking, and resolving every security risk Guard identifies.

Guard doesn't just find vulnerabilities — it guides them through a complete lifecycle. Each vulnerability moves through a structured workflow from initial detection through expert validation to final resolution, giving you a clear picture of what needs attention, what's been addressed, and what risks you've chosen to accept. For managed service customers, every vulnerability listed has been reviewed by Praetorian's expert security engineers before it reaches your queue.

The Discovery-Remediation Workflow

Every vulnerability in Guard follows a defined lifecycle. Understanding this workflow is key to effectively managing your security posture.

Vulnerability Statuses

Guard uses five statuses to track where each vulnerability stands in its lifecycle:

Detected — The vulnerability has been identified by Guard's scanning engines or imported from an integrated tool. It's awaiting review and triage. For managed service customers, Praetorian engineers review detected findings before promoting them.

Demonstrated — The vulnerability has been validated and confirmed as a real security issue affecting your attack surface. It requires remediation. When a vulnerability moves to Demonstrated, Guard can automatically create a ticket in your connected ITSM system (Jira, Azure DevOps, Freshdesk, etc.) to kick off your remediation workflow.

Resolved — The vulnerability has been remediated and verified as fixed. Guard continues to rescan resolved vulnerabilities — if the issue reappears, Guard automatically reopens it to Demonstrated status so nothing slips through the cracks.

Rejected — The vulnerability has been reviewed and determined to not require action. This typically means the finding is a false positive, a duplicate, out of scope for the current assessment, or otherwise not applicable to your environment. When rejecting a vulnerability, you can specify a reason: False Positive, Duplicate, Out of Scope, or Other.

Accepted — A deliberate decision has been made to accept the risk rather than remediate it. This is a conscious risk management choice — perhaps due to compensating controls, business constraints, limited impact, operational requirements, or a cost-benefit analysis that favors acceptance. Accepted vulnerabilities remain visible in your inventory so you can revisit the decision as circumstances change.

Workflow Paths

Primary Remediation Path:
Detected → Demonstrated → Resolved

This is the standard path. Guard detects a vulnerability, your team (or Praetorian's engineers) validates it, remediation work is performed, and the finding is closed once the fix is verified.

Rejection Path:
Detected → Rejected

When a detected finding is reviewed and determined to not be actionable — a false positive, out of scope, or not relevant to your actual attack surface.

Risk Acceptance Path:
Detected → Demonstrated → Accepted

When a real vulnerability is confirmed but a deliberate decision is made to accept the risk. The vulnerability is acknowledged, documented, and tracked without requiring remediation.

Reopening:
Guard continuously monitors your attack surface. If a resolved vulnerability is detected again during a subsequent scan, it is automatically reopened to Demonstrated status. This ensures that regressions and incomplete fixes don't go unnoticed.

Severity Levels

Every vulnerability is classified by severity, indicating the potential impact if exploited:

  • Critical — CVSS 9.0 and above. Remotely exploitable with severe impact. Requires immediate attention.

  • High — CVSS 7.0–8.9. Significant risk that should be prioritized for near-term remediation.

  • Medium — CVSS 4.0–6.9. Moderate risk, often requiring specific conditions to exploit.

  • Low — CVSS 0.1–3.9. Minor issues with limited impact.

  • Info — Informational findings that highlight areas to harden but may not require direct remediation.

  • Exposure — Configuration or exposure findings that expand your attack surface without representing a direct exploitable vulnerability.

The Vulnerabilities Page

When you navigate to the Vulnerabilities page from the left sidebar, you'll see a data table showing every vulnerability Guard has discovered across your attack surface. The table is designed to help you quickly triage, filter, and take action on findings at any scale.

Table Columns

Each row in the vulnerabilities table represents a single vulnerability. The following columns are available:

Status — The current lifecycle state of the vulnerability: Detected, Demonstrated, Resolved, Accepted, or Rejected. Each status is shown as a color-coded badge with an icon for quick visual scanning.

Severity — The severity classification of the vulnerability: Critical, High, Medium, Low, Info, or Exposure. Displayed as a color-coded tag.

Vulnerability — The name or identifier of the vulnerability, such as a CVE ID (e.g., CVE-2024-1234), a descriptive name (e.g., "SQL Injection"), or a scanner-specific identifier. This column cannot be hidden.

CVSS — The Common Vulnerability Scoring System score (0–10 scale) representing the base severity of the vulnerability according to the industry-standard scoring framework.

EPSS — The Exploit Prediction Scoring System probability (0–1 scale), indicating the likelihood that the vulnerability will be exploited in the wild within the next 30 days.

CISA KEV — Indicates whether the vulnerability appears in CISA's Known Exploited Vulnerabilities catalog. Vulnerabilities on this list have confirmed real-world exploitation and often come with mandatory remediation deadlines for federal agencies.

Public Exploits — Indicates whether publicly available exploit code exists for this vulnerability. Findings with public exploits carry elevated urgency.

Origin — Shows the source that identified the vulnerability, such as the scanning tool or integration that discovered it (e.g., Nuclei, Burp Suite Enterprise, Nessus, or a cloud integration name).

Tags — User-defined labels applied to the vulnerability for custom organization and grouping.

Ticket — Shows the linked ITSM ticket reference (e.g., a Jira issue key like PROJ-123) with a direct link to the ticket in your external system.

First Seen — The date the vulnerability was first discovered by Guard.

Last Seen — The date Guard most recently confirmed the vulnerability during a scan.

You can customize which columns are visible and reorder them using the column picker icon in the table header. Your column preferences are saved automatically.

Searching and Filtering

A search bar at the top of the table lets you quickly find vulnerabilities by typing part of their name, CVE ID, or associated asset.

Below the search bar, dropdown filters let you narrow down the table by any combination of:

  • Severity — Filter to Critical, High, Medium, Low, Info, or Exposure findings.

  • Status — Filter to Detected, Demonstrated, Resolved, Accepted, or Rejected vulnerabilities.

  • Source — Filter by the tool or integration that discovered the vulnerability (Nuclei, Burp Suite Enterprise, Nessus, Qualys, etc.).

  • Attack Surface — Filter by where the affected asset sits (External, Internal, Cloud, Application, Repository).

  • Tags — Filter by your custom tags.

  • CISA KEV — Filter to only vulnerabilities that are (or aren't) in the CISA Known Exploited Vulnerabilities catalog.

  • Public Exploits — Filter to only vulnerabilities that do (or don't) have publicly available exploit code.

  • SSO Identified — Filter by SSO-related vulnerability detection.

  • CVSS Score Range — Use the range slider to filter vulnerabilities within a specific CVSS score range (0–10).

  • EPSS Probability Range — Use the range slider to filter by exploit prediction probability (0–1).

  • Date Range — Filter by when vulnerabilities were first seen or last seen.

All filters are multi-select — you can choose multiple values within any filter. A "Clear Filters" button appears when any filters are applied, letting you reset everything with one click.

Sorting

Click any sortable column header to sort the table by that column. Click again to toggle between ascending and descending order. An arrow indicator in the header shows the current sort direction.

Selecting Vulnerabilities and Bulk Actions

Each row has a checkbox on the left. Select one or more vulnerabilities to reveal a bulk action bar with the following options:

Change Severity — Reclassify the selected vulnerabilities to a different severity level (Critical, High, Medium, Low, Info, or Exposure).

Change Status — Transition the selected vulnerabilities to a new workflow state:

  • Demonstrated — Mark as confirmed and requiring remediation.

  • Resolved — Mark as remediated.

  • Accepted — Accept the risk.

  • Rejected — Reject the finding (with reason selection).

Delete — Remove the selected vulnerabilities from your inventory.

Status changes through bulk actions trigger confirmation modals to prevent accidental transitions, and automatically create history entries recording who made the change and when.

Getting Started with No Vulnerabilities

If you're new to Guard and haven't discovered any vulnerabilities yet, the Vulnerabilities page presents a "Get Started" prompt offering three ways to begin:

  1. Auto Discover — Add seed domains or CIDR ranges and let Guard automatically discover your attack surface and scan for vulnerabilities.

  2. Configure Integrations — Connect vulnerability scanners like Nessus, Rapid7 InsightVM, Qualys, Burp Suite, or Invicti to import findings.

  3. Import Vulnerabilities — Upload vulnerability data from Qualys, Nessus, InsightVM, or NSA CSaaS.

The Vulnerability Detail Drawer

Click any row in the vulnerabilities table to open the detail drawer — a panel that slides in from the right side showing comprehensive information about a single vulnerability.

Drawer Header

At the top of the drawer, you'll see:

  • Vulnerability Name — The full name or CVE identifier with a copy button.

  • Share Button — Copies a direct link to this vulnerability's detail view.

  • Severity Badge — The color-coded severity level.

  • AI Analysis — When Guard's machine learning models have analyzed the finding, a prediction badge appears showing the recommended action (e.g., "AI Analysis: Recommend to open" or "Recommend to reject").

  • Vulnerability Status — The current workflow status badge.

  • First Seen / Last Seen — The dates when Guard first discovered and most recently confirmed the vulnerability.

Action buttons in the drawer header include Add Note, Add Tag, Remove Tag, Export, Auxiliary Information, and ticket management actions.

Overview Tab

The Overview tab is the default view and provides the essential details about the vulnerability.

Description — A detailed explanation of the vulnerability, including what it is, why it matters, and how it could be exploited. For CVE-linked vulnerabilities, this pulls from authoritative vulnerability databases.

For CVE-linked vulnerabilities, the Overview tab includes additional subtabs:

  • Description — The primary vulnerability description and remediation guidance.

  • Risk Score — CVSS base score breakdown and EPSS exploit prediction data, giving you both the theoretical severity and the real-world likelihood of exploitation.

  • Exploitation Activities — Known threat actor activity associated with this vulnerability, including whether it's being actively exploited in the wild.

  • MITRE — Mapping to MITRE ATT&CK techniques and CWE (Common Weakness Enumeration) classifications, showing where this vulnerability fits in the broader threat landscape.

Related Tickets — If the vulnerability is linked to an ITSM ticket (Jira, Azure DevOps, Freshdesk, etc.), the ticket reference, status, assignee, and a direct link are shown here.

Assets Impacted Tab

This tab shows every asset affected by the vulnerability. It displays an embedded assets table filtered to only the assets associated with this specific finding. You can search and filter the impacted assets by status, tags, and attack surface classification.

This tab is particularly useful for vulnerabilities that affect multiple assets — for example, a domain-level TLS misconfiguration that impacts all IPs under that domain, or a CVE that affects multiple servers running the same software version.

Evidence Tab

The Evidence tab provides the technical proof supporting the vulnerability finding. This is where you can see exactly what Guard (or an integrated scanner) observed to identify the issue.

Evidence File Selection — When multiple pieces of evidence exist for a vulnerability, a dropdown lets you navigate between them. The label format varies by finding type:

  • Git secrets show as organization/repository

  • Cloud resources show the resource display name or identifier

  • Web vulnerabilities show as dns:port (ip)

  • Web resources show the full URL

Evidence Details — Each evidence file displays:

  • The target URL or resource identifier where the vulnerability was observed.

  • Content length of the captured evidence.

  • The date the evidence was captured.

  • The current status of the associated asset.

Auxiliary Information — For vulnerabilities that benefit from additional context, authorized users can add supplementary documentation in markdown format. This is useful for recording exploitation details, remediation steps, or analyst notes that go beyond the automated evidence.

Each vulnerability shows only the evidence fields relevant to its specific type and discovery method, so some sections may appear blank when they don't apply to that particular finding.

History Tab

The History tab provides a complete audit trail of every change made to the vulnerability throughout its lifecycle. Each entry in the chronological timeline shows:

  • What changed — Status transitions (e.g., "Detected → Demonstrated"), severity modifications, tag additions or removals, note additions, and ticket associations.

  • When it changed — Precise timestamp of the change.

  • Who made the change — The user or system process that initiated the change.

  • Comments — Any notes provided with the status change explaining the reasoning.

For vulnerabilities analyzed by Guard's machine learning models, the history also records prediction details including model confidence scores.

This audit trail is essential for compliance reporting, incident review, and understanding the full story of how a vulnerability was managed from discovery through resolution.

Notes Tab

The Notes tab is a collaboration space for your team to discuss the vulnerability. Each note shows the author, timestamp, and content with full markdown formatting support.

You can:

  • Add notes — Click "Add Note" to create a new entry with rich markdown formatting.

  • Edit notes — Modify your own previously created notes.

  • Delete notes — Remove notes you've authored.

Notes are visible to all users who can view the vulnerability, making them ideal for documenting remediation plans, sharing context between team members, or recording decisions about risk acceptance.

How Vulnerabilities Are Discovered

Guard identifies vulnerabilities through a combination of its own scanning engines and integrated third-party tools. The approach varies by asset type and the nature of the vulnerability.

Native Scanning

Guard's built-in scanning capabilities cover a broad range of vulnerability types:

  • Web Application Scanning — Dynamic application security testing (DAST) that crawls and tests web applications for OWASP Top 10 vulnerabilities, injection flaws, authentication weaknesses, and more.

  • Network Vulnerability Detection — Identifies known vulnerabilities in network services based on service fingerprinting, version detection, and protocol analysis.

  • TLS/SSL Analysis — Evaluates certificate validity, cipher suite strength, protocol versions, and common TLS misconfigurations.

  • DNS Security — Checks for zone transfer vulnerabilities, dangling DNS records, subdomain takeover opportunities, and DNSSEC configuration issues.

  • Cloud Misconfiguration — Scans cloud resources imported from AWS, Azure, and GCP integrations for misconfigurations, overly permissive policies, and security best practice violations.

  • Secret Detection — Scans code repositories for exposed credentials, API keys, private keys, and other sensitive data that shouldn't be in source control.

  • Nuclei Templates — Runs an extensive library of Nuclei vulnerability detection templates covering thousands of known CVEs, misconfigurations, and exposure patterns.

Integrated Scanner Imports

Guard can import vulnerability findings from your existing security tools, consolidating everything into a single view:

  • Nessus — Import scan results from Tenable Nessus vulnerability assessments.

  • Rapid7 InsightVM — Import findings from InsightVM vulnerability management.

  • Qualys — Import scan data from Qualys vulnerability management.

  • Burp Suite Enterprise — Import web application security findings.

  • Invicti — Import DAST scan results.

  • CrowdStrike Spotlight — Import endpoint vulnerability data.

  • Orca — Import cloud and container security findings.

Enrichment and Context

Once a vulnerability is identified, Guard automatically enriches it with additional context:

  • CVSS Scoring — Maps findings to CVSS base scores for standardized severity classification.

  • EPSS Probability — Adds exploit prediction scores indicating real-world exploitation likelihood.

  • CISA KEV — Flags vulnerabilities that appear in CISA's Known Exploited Vulnerabilities catalog.

  • Public Exploit Detection — Identifies whether publicly available exploit code exists.

  • MITRE ATT&CK Mapping — Links vulnerabilities to relevant ATT&CK techniques and CWE classifications.

This enrichment ensures that every vulnerability in your inventory carries the context needed to make informed prioritization decisions.

Vulnerability Retention and Rescanning

Guard handles vulnerability lifecycle management automatically to keep your security posture accurate and current.

Time-to-Live for Detected Findings

Vulnerabilities in the Detected status have a default time-to-live (TTL) of 30 days. If a detected finding isn't acted upon within that window — meaning it isn't promoted to Demonstrated, Rejected, or any other status — it expires and is cleaned up automatically. This prevents stale, unreviewed findings from cluttering your inventory.

Once a vulnerability transitions out of the Detected state to any other status, the TTL is cleared and the vulnerability persists indefinitely until explicitly changed.

Continuous Rescanning

Guard continuously rescans confirmed vulnerabilities to verify their current state. This serves two critical purposes:

  1. Regression Detection — If a vulnerability that was marked as Resolved reappears during a subsequent scan, Guard automatically reopens it to Demonstrated status. This catches incomplete fixes, regressions from code deployments, and configuration drift.

  2. Status Freshness — The Last Seen timestamp is updated each time a vulnerability is confirmed, giving you confidence that the data reflects the current state of your environment.

Persistence of Confirmed Vulnerabilities

Once a vulnerability moves to Demonstrated, Accepted, or Resolved status, it remains in the system until explicitly changed. Guard maintains the complete history of all status changes, including who made each change and when, creating a comprehensive audit trail for compliance and reporting purposes.

Ticketing Integration

Vulnerabilities can be linked to your external ticketing systems to streamline remediation workflows. Guard integrates with:

  • Jira — Automatically create Jira issues when vulnerabilities move to Demonstrated status, and close them when resolved.

  • Azure DevOps — Sync vulnerability status with Azure DevOps work items.

  • Freshdesk — Create and track support tickets for vulnerability remediation.

When a vulnerability's status changes in Guard, the linked ticket is automatically updated with a comment noting the transition, the reason, and a link back to the vulnerability in Guard. If a resolved vulnerability is reopened due to regression detection, the associated ticket is also reopened automatically.

Need help or have questions? Our support team is ready to assist at support@praetorian.com. We're here to help you make the most of these vulnerability management capabilities.