Incidents
Incidents are automatically created when BleedWatch's correlation engine detects related findings across multiple sources. Instead of investigating isolated alerts, incidents group connected exposures into a single actionable case.
What Creates an Incident
An incident is generated when BleedWatch detects a cross-source correlation — the same secret, credential, or vulnerability appearing in multiple contexts. Examples:
| Correlation Pattern | Incident Created |
|---|---|
| AWS key found in npm package + same key in a GitHub repo | Compound secret exposure |
| Employee email in stealer logs + same email in HIBP breach | Multi-source credential leak |
| Database password in Docker image + open database port detected | Exposed infrastructure access |
| API token in public repo + same token triggered a honeytoken alert | Active exploitation detected |
Single-source findings remain in Findings — incidents only appear when multiple data points converge.
Incident Dashboard
The incident list shows:
| Column | Description |
|---|---|
| Severity | Highest severity among correlated findings (critical / high / medium / low / info) |
| Title | Auto-generated description of the correlation |
| Sources | Number of distinct sources contributing to this incident (badge) |
| Findings | Total number of individual findings linked |
| Status | Current incident state |
| Last Seen | Most recent finding activity in this incident |
Filtering and Sorting
- Filter by severity — Focus on critical incidents first
- Filter by status — Show only active, resolved, or suppressed incidents
- Sort options — By severity (ascending/descending), finding count, or last seen date
- Export to CSV — Download the incident list for external tracking
Incident Statuses
| Status | Meaning |
|---|---|
| Active | The incident is open and requires investigation |
| Resolved | All findings in the incident have been remediated |
| Suppressed | The incident has been acknowledged but deprioritized (requires justification) |
Incident Detail View
Click any incident to see the full detail page:
Correlation Summary
A visual breakdown of which sources contributed findings to this incident, showing how the exposure spans across your attack surface.
Linked Findings
Every individual finding that contributed to the incident, with:
- Finding title and type
- Source (npm, Docker, GitHub, dark web, etc.)
- Severity and status
- Detection timestamp
- Link to the full finding detail
Exposure Timeline
A chronological view of when each finding was detected, showing how the exposure evolved over time. This is critical for incident response — it tells you:
- When the exposure first appeared
- How long it was present before detection
- Whether additional sources were compromised over time
Responding to Incidents
Step 1: Assess Scope
Review the correlation summary to understand which systems are affected. A multi-source incident means the exposure has spread beyond a single repository or package.
Step 2: Prioritize by Severity
Critical incidents with active exploitation indicators (honeytoken triggers, dark web listings) take precedence over medium-severity credential correlations.
Step 3: Remediate All Linked Findings
An incident is only truly resolved when every linked finding has been remediated. Fixing one source while leaving others exposed means the attacker still has access through alternate paths.
Step 4: Mark as Resolved
Once all linked findings are confirmed remediated, update the incident status to Resolved. BleedWatch tracks the resolution timestamp for compliance evidence.
Suppressing an incident removes it from your active dashboard but does not remediate the exposure. Only suppress incidents that have been investigated and determined to be acceptable risk.
Troubleshooting
No Incidents Showing
Incidents require multi-source correlations. If you only monitor one asset type (e.g., only npm packages), correlations are less likely. Add diverse asset types (domains, Docker registries, GitHub organizations) to enable cross-source correlation.
Incident Still Active After Fixing
An incident remains active until all linked findings are resolved. Check the finding list in the incident detail — one or more findings may still be open.
Too Many Low-Severity Incidents
Use severity filtering to focus on critical and high incidents. Consider configuring alert routing rules in Alerts → Workflows to only notify on high-severity incidents.
Related
- Findings — View individual findings without correlation
- Attack Surface — Visualize incident relationships in the graph
- Alerts — Configure notifications for new incidents
- Workflows — Automate incident response actions