Skip to content

Threats

The Threats page lists security findings with affected asset context so operators can understand what is happening in an organization and where it applies.

Threat is the common hxEASM domain entity. Vulnerability is one Threat type, alongside Data Leak, Misconfiguration, Phishing, and Employee exposure records.

Threat risk_score uses a canonical 0-100 scale. CVSS remains a separate 0-10 technical severity score. Risk Model V1 is documented as a proposed, not-yet-implemented contextual prioritization model in risk-model-v1.md; the current risk_score field is a simpler technical score and should not be interpreted as that full proposal.

Threat Types

Stored value Label Notes
vulnerability Vulnerability Technical vulnerability finding. Supports CVE, CWE, CVSS, Has Exploit, and Retest.
data_leak Data Leak Safe summary of exposed data. Do not store raw secrets in threat fields.
misconfiguration Misconfiguration Configuration issue such as an exposed admin interface or weak policy.
phishing Phishing Impersonation or phishing infrastructure finding.
employee Employee Employee/account exposure record. The employee is not treated as malicious.

Common Fields

Threat API responses include:

  • id
  • organization_id
  • asset_id when a Threat is tied to an Asset
  • threat_type
  • title
  • description
  • severity
  • status
  • close_reason
  • risk_score on a 0-100 scale
  • remediation
  • source_plugin
  • external_id
  • first_seen_at
  • last_seen_at
  • type_details

Asset context is joined at read time when available: asset_type, asset_value, asset_criticality, and asset_source_plugin.

Plugin-discovered vulnerability Threats remain deduplicated by stable finding identity. When the same finding is detected in later scan jobs, hxEASM updates the existing Threat and records a scan detection history row instead of creating another Threat row. Threats created before detection history was introduced may show no Scans history.

Administrators and hackers can add a plugin-discovered finding to persistent exclusions. Exclusions are scoped to organization, affected Asset, and external ID; the source plugin is retained as informational metadata for the rule that was originally created. Future detections matching that organization, Asset, and external ID are suppressed regardless of which plugin reports them. The historical Threat remains in the database and is not automatically closed, deleted, or marked false positive. Findings without an external ID cannot be excluded in V1. Exclusions can be managed from Settings -> Scans -> Threat exclusions; removing an exclusion affects future detections only and does not delete historical Threat or detection data.

Vulnerability-Specific Fields

Only threat_type=vulnerability supports:

  • cve
  • cwes
  • references
  • cvss_score
  • has_exploit
  • has_exploit_source
  • affected_host
  • affected_port
  • affected_protocol
  • affected_service
  • affected_url
  • Retest

The backend rejects vulnerability-specific fields for non-vulnerability Threat types.

Filtering

The organization Threat list supports these query parameters:

Parameter Meaning
threat_type One of vulnerability, data_leak, misconfiguration, phishing, or employee.
severity Severity filter.
status Workflow status filter.
asset_id Exact affected asset UUID.
asset_type Joined asset type, such as ip, service, or webapp.
asset Case-insensitive search across joined asset value plus metadata host/url fields.
source_plugin Source plugin, for example nuclei, nmap_vulns, or manual.
port Vulnerability metadata port filter.
protocol Vulnerability metadata protocol filter.
has_exploit Vulnerability-only filter. When used, results are narrowed to vulnerability Threats.

Example:

GET /api/v1/organizations/{org_id}/threats?threat_type=vulnerability&asset_type=service&asset=192.0.2.10&source_plugin=nmap_vulns

Manual Threats

Admin and hacker users can create Threats manually from the Threats page. Client users cannot create or modify Threats outside the customer workflow transitions.

Manual creation starts every Threat as:

status = new
close_reason = null
source_plugin = manual

Vulnerability Threats require an affected Asset. Other Threat types may be organization-level when a single Asset association is not appropriate.

Status Workflow

Threats use a formal workflow that separates state from closure reason:

status = new | active | in_progress | review | closed
close_reason = fp | fixed | skipped

close_reason is present only when status=closed. New manual and plugin-discovered Threats start as new.

Current Actor Action Next Reason
New admin / hacker Confirm Active -
New admin / hacker Mark false positive Closed FP
Active client Start remediation In Progress -
Active client Accept risk Closed Skipped
In Progress client Submit for review Review -
Review admin / hacker Mark fixed Closed Fixed
Review admin / hacker Return to active Active -

Administrators may perform valid workflow transitions as an operational override. They cannot skip the workflow graph, reopen closed Threats, or set a close reason on a non-closed Threat.

Retest is available only for vulnerability Threats in review. Retest does not automatically infer whether a vulnerability is fixed.

Discussions

Each Threat has an organization-scoped discussion thread. Admin and hacker users can create internal or client-visible comments. Client users can read only client-visible comments, and their own submitted comments are always client-visible.

Mention autocomplete resolves users by ID. Internal comments may mention admins and hackers only. Client-visible comments may also mention client users assigned to the same organization.

Mentioned users receive in-app notifications on /profile. External Telegram, email, webhook, browser push, or WebSocket delivery for mentions is not implemented.

See vulnerability-discussions.md for the full permissions and notification model.

API Compatibility

The canonical API routes are /threats. Existing /vulnerabilities routes remain compatibility aliases for vulnerability-oriented clients, but new integrations should use the Threat routes and the threat_type field.