Appearance
Security Tool Integrations
Where to find it: Integrations, then Security Tool Integrations (/integrations/security-tools).
Security Tool Integrations is OrviQ's ingestion engine for enterprise vulnerability scanners and network configuration analyzers. It connects to vulnerability management infrastructure and configuration audit tools to ingest technical findings, correlate host assets, and feed continuous control indicators.
Requires the integrations_security_tools entitlement.
Ship-dark behavior
Security Tool Integrations ships dark. When the integrations_security_tools entitlement is disabled, the module is entirely hidden from the platform navigation, rather than rendering a locked discovery item. API endpoints return 403 Forbidden.
Supported Scanner Adapters
The engine includes native adapters and parsers for 9 security tools:
| Adapter Key | Vendor & Tool | Ingestion Modes | Formats Supported | Telemetry Ingested |
|---|---|---|---|---|
tenable_sc | Tenable Security Center | API pull, File import | tenable_sc_api, tenable_sc_csv, nessus_xml | Host vulnerabilities, scan metadata, discovered assets |
nessus | Tenable Nessus (Pro/Expert) | File import, API pull | nessus_xml, nessus_api | Network vulnerability scan reports, host inventories |
tenable_io | Tenable Vulnerability Management | API pull | tenable_io_api | Cloud vulnerability exports, asset workbench |
qualys | Qualys VMDR | API pull, File import | qualys_api, qualys_xml, qualys_csv | Host List Detection findings, vulnerability posture |
rapid7 | Rapid7 InsightVM / Nexpose | API pull, File import | rapid7_api, rapid7_csv | Asset vulnerability assessments, security console data |
microsoft_defender | Microsoft Defender | API pull | defender_api | Machine vulnerabilities, device compliance posture |
crowdstrike | CrowdStrike Falcon Spotlight | API pull | crowdstrike_api | Spotlight real-time vulnerabilities per sensor endpoint |
nipper | Titania Nipper | File import, API pull | nipper_xml, nipper_csv, nipper_json, nipper_api | Firewall, switch, and router configuration audits |
prowler | Prowler | File import | prowler_ocsf, prowler_csv | Cloud security checks, CIS benchmark evaluations |
Ingestion Workflows
Telemetry enters OrviQ through two distinct paths:
1. Automated API Pull
For reachable, network-connected scanners (e.g. Tenable Security Center, Qualys, Microsoft Defender, CrowdStrike):
- Connections are configured in
/integrations/security-tools?tab=connectionsusing least-privilege service credentials. - Ingestion runs asynchronously on a configurable cadence (or on-demand via Sync Now).
- Watermark timestamps ensure incremental synchronizations only fetch delta changes since the last run.
2. Governed File Import (Maker-Checker)
For air-gapped enclaves, offline networks, or ad-hoc security assessments, users can upload raw scan reports (.nessus, Tenable CSV, Nipper XML/JSON, Qualys XML/CSV, Rapid7 CSV, Prowler OCSF/CSV).
To guarantee data integrity and prevent unauthorized alteration of audit observations, file imports enforce strict Maker-Checker Segregation of Duties:
- Upload (Maker): An authorized operator with
integration.importuploads the scan file. - Parsing & Preview: The background worker parses the file, calculates SHA-256 integrity hashes, extracts hosts and findings, and builds a preview summary. The job status transitions to
awaiting_confirmation. - Independent Confirmation (Checker): A separate user holding
integration.confirmreviews the summary preview (total hosts, total findings, severity distribution). The checker either confirms the import or rejects it with a mandatory reason code. - Enforced Separation: The platform strictly enforces that the user who uploaded the file (
requested_by) cannot confirm it (confirmed_by != requested_by).
Integration Sync Jobs (ISJ-)
All background import and synchronization operations run as durable, leased Integration Sync Jobs (ISJ-YYYY-NNNN):
- Job Lifecycle:
queued→running→awaiting_confirmation(for file imports) →succeeded/failed/rejected. - Fault Tolerance: Jobs use distributed leasing with automatic retry on transient infrastructure failures.
- Full vs. Delta Syncs: A full sync updates the entire target asset set. Only full syncs have the authority to mark absent findings as
fixed.
Scanner Findings (SFN-)
Ingested technical vulnerabilities and configuration deviations are recorded as Scanner Findings (SFN-YYYY-NNNN).
Scanner findings are NOT Compliance Findings
A ScannerFinding (SFN-) is fundamentally distinct from a ComplianceFinding (FND-):
- Volume & Automation: Scanner findings arrive in high volume (thousands per scan), have machine lifecycles, and are deduplicated automatically on
sha256(tenant, connection, asset, external_ref, port, protocol). - Auto-Resolution: When a subsequent full scan verifies that a vulnerability is no longer detected, the engine automatically transitions the finding from
opentofixed. - Compliance Findings (
FND-): In contrast, compliance findings represent formally governed deficiencies with human ownership, Three Lines of Defence segregation, and audit sign-off.
Machine Lifecycle States
| Status | Meaning |
|---|---|
open | Active finding detected on the asset |
fixed | Automatically resolved because a later full scan confirmed its absence |
reopened | Previously fixed finding detected again on a subsequent scan |
risk_accepted | Covered by an approved, active governed exception (EXC-YYYY-NNNN) |
false_positive | Formally verified and marked as a non-issue by an authorized analyst |
Severity Normalization
Different scanners use disparate severity conventions (e.g. Nessus numeric 0–4, Tenable VPR ratings, Qualys 1–5 levels, Nipper text ratings). OrviQ normalizes all scanner ratings into a unified 5-tier vocabulary:
| Normalized Severity | Nessus Numeric | CVSS v3 Baseline | Nipper / Qualitative Words |
|---|---|---|---|
| Critical | 4 | 9.0 – 10.0 | Critical |
| High | 3 | 7.0 – 8.9 | High |
| Medium | 2 | 4.0 – 6.9 | Medium, Moderate |
| Low | 1 | 0.1 – 3.9 | Low |
| Informational | 0 | 0.0 | Info, Informational, None |
Vendor authority
Vendor-adjusted severity is preserved as authoritative. For instance, if Tenable adjusts a CVE's base CVSS score using Predictive Prioritization (VPR), the engine honors the vendor's contextualized rating rather than falling back to uncontextualized CVSS metrics.
Discovered Asset Provenance & Reconciliation
When a scanner reports a host, OrviQ reconciles it with the enterprise asset register using an identification ladder:
$$\text{External Scanner UUID} \longrightarrow \text{MAC Address} \longrightarrow \text{FQDN} \longrightarrow \text{IP Address} \longrightarrow \text{Hostname}$$
- Many-to-One Asset Correlation: Multi-scanner environments often inspect the same physical host through different tools (e.g. Tenable host UUID and Nipper device name). OrviQ creates an
AssetDiscoveryIdentity(ADI-) per connection, linking multiple scanner identities to a single canonical Asset (AST-YYYY-NNNN). - Review Queue for New Hosts: Discovered hosts that match no existing asset enter the review queue with
discovery_review_status = "unassigned". An operator withasset.discovery_reviewmust approve (reviewed), merge (merged), or ignore (ignored) the host. - Human Governance Protection: Scanners populate technical attributes (IP, MAC, OS, FQDN). They never overwrite human-governed attributes (
owner,custodian,criticality,data_classification,environment,hosting_location). - Absence is not Decommissioning: If a host disappears from a scan, its identity is marked
staleormissing. The asset is never auto-decommissioned; asset decommissioning remains a formal human governance event.
Governed Finding Triage & Promotion
A raw scanner finding remains technical telemetry until a human analyst promotes it into the governance lifecycle:
- Raise as Compliance Finding (
FND-YYYY-NNNN): Promotes the observation to a formal governed finding, initiating the Three Lines of Defence remediation workflow. - Promote to Risk (
RSK-YYYY-NNNN): Escalates the vulnerability to the enterprise risk register for inherent and residual risk scoring. - Accept via Governed Exception (
EXC-YYYY-NNNN): Links the finding to a formal exception request with compensatory controls, expiration dates, and maker-checker approval. - Remediate via Action Plan (
ACT-YYYY-NNNN): Creates trackable remediation milestones assigned to IT engineering teams. - ITSM Ticket Write-Back: Dispatches bi-directional remediation tickets to ServiceNow or Jira.
Semantic Doctrine
Semantic Doctrine: Scanners & Assurance
- Scanner finding != confirmed control failure: Ingesting a vulnerability report does not automatically prove a control has failed. Controls are evaluated against indicator rules, compensating safeguards, and scope applicability.
- Integration connection != compliance: Successfully scheduling scanner syncs demonstrates data acquisition; it does not satisfy an obligation or establish regulatory compliance.
- Evidence != effectiveness: Ingested vulnerability observations provide evidence inputs. Determining control operating effectiveness requires defined coverage thresholds and human assessor validation.
Permissions Reference
| Action | Permission Key | Required Role(s) |
|---|---|---|
| View scanner integrations, jobs, and findings | integration.read | Admin, Compliance Manager/Officer, Risk Manager, Auditor |
| Configure connections and run API syncs | integration.manage | Tenant Admin, Compliance Manager |
| Upload scanner report files (Maker) | integration.import | Tenant Admin, Compliance Manager, Compliance Officer |
| Confirm previewed scanner import (Checker) | integration.confirm | Tenant Admin, Compliance Manager (never the uploader) |
| Review discovered assets (Approve/Merge/Ignore) | asset.discovery_review | Tenant Admin, Compliance Manager, Compliance Officer |