Skip to content

Working Through Findings

The findings list for an environment is where operational triage happens. This guide walks through the workflow for reviewing, evaluating, and acting on findings efficiently.

Accessing Findings

  1. Navigate to Environments in the left sidebar.
  2. Select your environment.
  3. Click the Findings tab.

The findings list shows all CVE-to-asset matches for this environment, sorted by BCS score by default.

Finding Card Information

Each finding in the list shows:

  • CVE ID and BSID: The NVD and BreachSpider identifiers.
  • Affected asset name: Which of your assets this CVE matches. Example: "PLC-A-Line3".
  • Severity badge and BCS score: Color-coded severity with the BCS exploitation priority.
  • KEV badge: Red badge if in the KEV catalog.
  • Exploit badges: EXPLOIT (orange) for public exploit, PoC (yellow) for proof-of-concept.
  • Match confidence tier: How precisely the CVE was matched to your asset.
  • Acknowledge button: Start the acknowledgment workflow.
  • Create Ticket button: Create a remediation ticket from this finding.

Match Confidence Explained

The match confidence tier tells you how precisely the CVE was matched to your asset:

HIGH: Your asset's version falls within the confirmed affected version range for this CVE. The match is specific and highly reliable. Very few false positives at this tier. Act on these findings.

Example: Your asset is Siemens S7-1500 V2.9.4. The CVE affects S7-1500 versions 2.0 through 3.0. High-confidence match.

MEDIUM: Your asset's product matches but the version is unspecified or the CVE's affected version range is broad. The match is likely relevant but not version-confirmed. Verify with the vendor advisory to confirm your specific version is affected.

Example: Your asset is Siemens S7-1500 (no version specified). The CVE affects S7-1500. Medium-confidence match because we cannot confirm version overlap.

LOW: Your vendor matches but no product-level match was confirmed. The CVE affects a different product from the same vendor, or the product match is fuzzy. Check the CVE detail page to see if your specific product is listed.

Example: Your asset is Siemens S7-1500. The CVE affects Siemens SCALANCE X switches. Low-confidence match because only the vendor matches.

Filtering Findings

Use the filter bar above the findings list to narrow your view:

  • Severity: Critical, High, Medium, Low. Select one or more.
  • Layer: OT, OS, NETWORK. Filter by who remediates.
  • KEV Only: Show only confirmed-exploited CVEs.
  • Patch Status: Patched, Unpatched, Partial.
  • Acknowledged: Show only acknowledged, only active, or all.
  • Match Confidence: HIGH, MEDIUM, LOW.

The Efficient Triage Workflow

For a productive triage session, work through findings in this order:

Step 1: KEV Findings First

Filter to KEV Only. These are confirmed actively exploited. Every KEV finding should have a documented action: patch applied, compensating control in place, or ticket created. Leave no KEV finding unreviewed.

Step 2: Critical with Exploits

Remove the KEV filter. Filter to CRITICAL severity with exploit_maturity = FUNCTIONAL or WEAPONIZED. These are severe vulnerabilities with working attack code. High probability of being targeted next.

Step 3: Remaining Critical and High

Review remaining CRITICAL and HIGH severity findings. For each one:

  1. Read the BCS score and factor breakdown.
  2. Check patch availability.
  3. Read the SAGE summary for ICS-specific context.
  4. Decide: patch, compensating control, accept risk, or investigate further.

Step 4: Document Every Decision

For each finding you review:

  • If patching: Create a ticket to track the remediation. Acknowledge the finding after the patch is applied.
  • If compensating control: Acknowledge with reason: compensating_control. Document the control in the notes.
  • If not applicable: Acknowledge with reason: not_applicable or false_match.
  • If accepting risk: Acknowledge with reason: accepted_risk. Document the business justification.
  • If escalating: Acknowledge with reason: escalated. Create a ticket and assign to the responsible team.

Do not leave findings in an unreviewed state. Even a "monitoring" note as an acknowledgment creates audit trail evidence that you were aware of the vulnerability.

Bulk Operations

For environments with many findings, the findings list supports bulk actions:

  • Select multiple findings using the checkboxes.
  • Click Bulk Acknowledge to acknowledge all selected with the same reason.
  • Click Bulk Ticket to create tickets for all selected.

Use bulk acknowledge for groups of findings that share the same disposition (e.g., all LOW-confidence vendor-only matches marked as not_applicable).