Vulnerability Management

Scope

Vulnerability handling becomes expensive when it is detached from ownership and execution reality. This guide keeps the public-safe operating model and removes internal implementation detail.

SSOT Document – Single Source of Truth for vulnerability management operational procedures, setup guides, and troubleshooting.

Related SSOT documents: - Architecture: vulnerability-management.md – System design and data models - Functional: vulnerability-management.md – API endpoints, formulas, decision flows - Manual: patching.md – Patch operations - Manual: compliance.md – Compliance operations - Architecture: alerts-monitoring.md – Alert and incident management

Viewing Vulnerabilities

Dashboard (the relevant workflow > Vulnerabilities): - Overview tab: Stats grid (total CVEs, affected hosts, severity breakdown, CISA KEV count), top 10 CVEs by host count, aging buckets, and a 30-day detection trend. If the overview load fails, the page shows an inline retryable error banner instead of a blank shell. - KB Mappings tab: KB-to-CVE cross-reference table showing which Windows KB patches fix which CVEs. Searchable by KB number or CVE ID. Shows severity, CVSS, affected host count, and data source (CVE advisory vs. patch DB). Results are scoped to your account (only CVEs affecting your hosts appear). When an organization filter is applied, both advisory-backed and patch-backed mappings respect the org scope. Pagination uses server-provided totals for accurate page navigation - Remediation tab: Urgency breakdown (critical/high/medium/low bands), patch availability stats, patch approval status. “Deploy Auto-Remediation” button per organization (requires security.manage) - Data Sources tab: Sync source status, last sync times, per-source sync buttons - Remediation Policy tab: Auto-remediation severity gates, batch limits, change control settings, and an org-level scheduled matching interval override

Note: Sync, match, and bridge operations run in the background. The dashboard shows “started” confirmations — check the Data Sources tab for progress.

Filtering: - By severity: critical, high, medium, low - By CISA KEV status - By whether hosts are affected - By search (CVE ID or title)

Export and bulk actions: - Export CSV downloads the current filtered vulnerability inventory for the active account. - Bulk acceptance requires a reason and can include an optional expiry datetime. The action updates the affected HostVulnerability records and synchronizes linked alerts/incidents through lifecycle sync.

Triggering Manual Operations

Trigger vulnerability sync: Without source, syncs all 5 sources plus exploit enrichment. NVD sync can take minutes; CISA KEV is fast. USN/RHSA/MSRC vary by advisory volume. All sync operations run in the background (202 response).

Trigger host matching:

Trigger vuln-patch bridge: Returns 202 (async). Links CVEs to available patches and computes urgency scores.

Trigger auto-remediation: Auto-approves patches for qualifying vulnerabilities and creates deployment.

Export vulnerability inventory: Exports the filtered vulnerability inventory for the current account. CSV is the default response format.

Bulk accept risk: Accepts risk for all affected host-vulnerability records that match the selected CVEs. Requires security.manage.

a. Checking Operation Status

Check operation status: Returns the current state of match and bridge operations: - status: idle, running, completed, or failed - started_at / completed_at: timing of last run - duration_seconds: how long the operation took - hosts_processed / items_processed: work completed - last_error: error message if the last run failed

Use this to verify that manual match/bridge triggers have completed before checking dashboard data.

The operation status is displayed in two places in the UI: 1. Data Sources tab: Full status card showing operation name, status badge, last run time, duration, hosts/items processed, and any error messages 2. Overview tab: Compact status indicators showing operation name and last completion time

Risk Acceptance

Accept risk for a vulnerability:

Key behaviors: - Accepted vulns remain visible in dashboards but are excluded from remediation - Acceptance survives re-matching – the matcher does NOT re-open accepted vulns - Lifecycle sync resolves linked alerts when risk is accepted - In the host-detail UI, the risk acceptance form includes an optional expiry date picker. If no date is set, the acceptance is permanent until manually revoked.

Revoke risk acceptance:

Source management access: Enabling or disabling vulnerability data sources () requires platform administrator access. This ensures tenant-level users cannot toggle global data pipelines that affect all tenants.

Exploitability Assessment

View assessments for a host:

Trigger fingerprint-based assessment: Uses the host’s fingerprint baseline to auto-detect: - Network reachability of vulnerable services - Whether affected process is running - Firewall rules as compensating controls

Manual override:

Score interpretation: | Score Range | Meaning | |-------------|---------| | 0.8 - 1.0 | Highly exploitable – immediate action needed | | 0.5 - 0.8 | Moderately exploitable – standard remediation | | 0.2 - 0.5 | Low exploitability – schedule remediation | | 0.0 - 0.2 | Minimal risk – compensating controls effective |

Remediation Summary

Returns: - Urgency breakdown: count at each tier (0-25, 26-50, 51-75, 76-100) - Patch availability: vulns with matched patches vs without - CISA KEV count with/without patches

The Overview tab also shows: - Aging buckets for active vulnerabilities: 0-7, 8-30, 31-90, and 90+ days - A 30-day detection trend chart based on detected_at

Common Vulnerability Scenarios

Scenario: New critical CVE in CISA KEV 1. CISA KEV sync runs daily, marks CVE as KEV + exploit_available 2. Vuln matching detects affected hosts on the next due scheduler tick (default every 6 hours, with optional org-level cadence overrides) 3. Exploitability assessment runs automatically 4. Vuln-patch bridge matches to available patches 5. If remediation policy qualifies it: auto-approve patches, create deployment 6. If no patch available + emergency_mitigation_allowed: config-only mitigation applied

Scenario: Investigating a specific host 3. Check urgency_score and matched_patch_kb on each host-vulnerability

Scenario: False positive vulnerability 1. Verify the version detection is correct (check installed_version vs fixed_version) 2. If it’s a genuine false positive from product name collision: accept risk with explanation 3. The vendor enforcement (_vendor_matches()) should prevent most false positives