Using Threat Landscape and Vulnerability Triage

Vigil Active Defense turns every protected device into a security sensor: the agent scans the filesystem for malware and catalogs installed software for CVE matching against NVD and OSV data. Two Dashboard pages present the results. Threat Landscape (/security-dashboard) gives a realm-level view of the security posture, and Vulnerability Triage (/triage) is the working queue where findings are reviewed and decided.

This guide is procedural: enabling scans, reading the dashboard, working through findings, and building suppression rules without hiding real risk. For the underlying detection architecture, see The Vigil Subsystem: Local Threat Detection.

1. Enabling Scans on a Device

Scanning is configured per device. Open the device detail view and select the Security tab.

1. Scanning scope: choose Full System or select individual partitions. The scope applies to both scheduled and manual scans.
2. Malware Protection: enable the Background Scheduler and pick a frequency: Hourly, Every 6 Hours, Every 12 Hours, Daily (24 Hours), or Weekly.
3. Vulnerability Inventory: enable Software Inventory so the agent catalogs installed software for CVE matching, and set the Inventory Frequency (Every 6 Hours, Every 12 Hours, or Daily). Leave this off on high-privacy systems where no software metadata may be collected.
4. Click SAVE CHANGES. The new policy is pushed to the device immediately; if the device is offline, the policy applies at its next connection and is enforced locally by the agent.

Manual scans and the daily quota: the SCAN NOW button triggers an immediate on-demand scan. Each device has a daily scan quota, shown next to the button (for example, QUOTA: 1 / 3 Scans Used), which resets at 00:00 UTC. When the quota is exhausted, the button shows LIMIT REACHED until the reset. Scheduler frequencies that would exceed the daily limit are disabled in the dropdown - Hourly, for example, requires a daily limit of at least 24.

A device that has never completed a scan has no security verdict: its risk badge shows a neutral NO DATA state, not a green "Secure". Treat NO DATA as a coverage gap - run a manual scan, or verify that the scheduler and the software inventory are enabled on that device.

2. Reading the Threat Landscape

Open Threat Landscape (/security-dashboard) from the sidebar. All charts and history tables on the page follow the time range selector in the header: the last 7, 30 (default), or 90 days, or a custom date range.

KPI Cards

• ACTIVE THREATS - open findings across the realm, with CRITICAL and HIGH counts broken out. Investigate these first.
• SCANS (24H) - how many devices completed a scan in the last 24 hours, against the total device count. A low ratio indicates coverage gaps.
• FILES SCANNED - inspected data volume in the last 24 hours.
• TOTAL FIXED - findings closed by remediation (patched software or removed malware).

Charts and Flight Recorder

• THREAT DETECTION STREAM - vulnerabilities and malware detected per day.
• ENGINE THROUGHPUT - files scanned and scan frequency per day; useful for spotting devices that stopped scanning.
• RISK & REMEDIATION - critical severity count against remediation velocity, showing whether you are closing findings faster than you accumulate them.

The FLIGHT RECORDER LOG table lists one row per day: scans performed, malware and vulnerability counts, and an ALERT / OK status. The LATEST VULNERABILITY DETECTIONS table shows the most recent findings (detection time, severity, vulnerability ID, package, device, status); click a row to open the finding details.

Priority Devices

The PRIORITY DEVICES panel lists up to five devices with active findings, sorted worst-first by critical count, total active findings, and risk score. Clicking a device deep-links into Vulnerability Triage with that device pre-filtered - the fastest entry point for daily triage. When no device has active findings, the panel shows "All devices secure".

Generate Report

Generate Report in the header produces a PDF security report:

1. Choose the scope: Whole realm or Single device.
2. Select the sections to include: Fleet summary (realm scope only), Active findings per device, Resolved / ignored history, and Space for handwritten notes for printed review copies.
3. Click Generate to download the PDF.

Use the realm scope for management and compliance reporting, and the per-device scope for handover to the team remediating that machine.

3. Working Through Findings

Open Vulnerability Triage (/triage). The page has three tabs:

• ACTIVE - findings currently requiring attention, with the open count in the tab label.
• RESOLVED / IGNORED - the combined history: findings auto-resolved after the underlying software was patched, findings suppressed by a triage decision, and snoozed items.
• SUPPRESSION RULES - standing rules that automatically suppress matching findings (Section 4).

Finding What to Work On

• Filter by device with the dropdown (it lists per-device finding counts), and search by CVE ID, package, or device name.
• Sort columns by severity, vulnerability ID, affected asset, or detection date. Severity sorts by score, so the worst findings land on top.
• Switch between Flat list and Group by device. The grouped view renders one accordion per device with severity count chips, ordered worst-first - practical when a few machines account for most findings.
• A link of the form /triage?device=<id> opens the page with the device filter pre-applied. The PRIORITY DEVICES panel uses this, and you can share such links within the team.

Click a finding row to open the details dialog: severity and score, the vulnerability ID and its source, the affected package and version, a Fixed in: <version> banner when a fix version is known (or No fix available), the CVE description and vector string, first detected / last seen timestamps, and the current triage status with its note. The fixed-in version tells you which package update clears the finding.

The DECIDE Dialog

Click DECIDE on a finding, select one of the four decisions, and enter a justification note:

The justification is stored with the decision and included in the audit record, so write it for a future reader: what you checked and why the decision is safe. Click Submit Decision to apply.

Bulk Triage and CSV Export

• For a batch of similar findings (for example, the same backported package across several servers), select them with the checkboxes - the header checkbox selects everything currently filtered - and click DECIDE in the bulk action bar. One decision with one justification is applied to all selected findings. Bulk decisions cannot create suppression rules; create rules from a single finding instead.
• Export CSV downloads the currently filtered ACTIVE list (severity, vulnerability ID, package, fixed-in version, device, detection time, triage status and note) for reporting or spreadsheet analysis.

Findings resolved by a software update close themselves: the next inventory scan no longer matches the vulnerable version and marks the finding as fixed. To reactivate a suppressed finding after the environment changes, open it in the RESOLVED / IGNORED tab and submit Confirm (Active).

4. Building Suppression Rules Safely

One-off decisions handle one-off noise. For recurring noise, create a standing rule from a finding's DECIDE dialog via Create Rule:

• Scope: Single Device or Entire Realm.
• Target: By Package (all findings for that package) or By Vulnerability ID (only that specific CVE).
• Reason: False Positive, Accepted Risk, or Not Applicable, plus a free-text comment.

Rules automatically suppress future matching findings, and existing matching findings are updated on the next scan. All rules are listed in the SUPPRESSION RULES tab and can be deleted there; deleting a rule stops the suppression for subsequent scans.

Rules are powerful because they act on every future finding, including findings on devices you add later. Work safely:

1. Narrow before broad. The dialog pre-selects the broadest combination (Entire Realm, By Package). Unless that is genuinely what you want, start with Single Device plus By Vulnerability ID, and widen only when the same rule proves necessary elsewhere.
2. Treat the comment as audit evidence. Reference the basis for the rule: a vendor backport advisory, a network-isolation note, a compensating control. A realm-wide package rule without a comment is an audit finding waiting to happen.
3. Review rules regularly. A rule created for an isolated server becomes wrong the day that server goes online. Revisit the SUPPRESSION RULES tab after infrastructure changes and delete stale rules.

For what qualifies as a false positive and for the full decision lifecycle, see Vigil False Positives and Suppression Management.

5. Permissions and Audit Trail

Recording triage decisions and managing suppression rules requires the realm permission vigil.triage_risks. Users without it can view findings but cannot decide or suppress; platform support roles are read-only. Every decision - the deciding user, the chosen status, and the justification - is recorded in the realm's audit trail on the Events & Logs page (/events), and suppressed findings remain visible in the RESOLVED / IGNORED tab. Suppression hides findings from the active queue, never from the record.

Related: Ransomware Protection: Response Policies covers the entropy-based ransomware detector, a separate Vigil capability with its own realm policy.

StateWarden: Resilience Engineered.