Findings come inVulnerability management
Qualys
Pulls Qualys VM detections into the shared finding table, resolved to the same assets your other tools report on, so one host with one problem is one piece of work.
What the connector does
- Host detections from the asset groups you name
- QIDs mapped to their CVEs, and CVEs enriched with EPSS and KEV
- Asset identity reconciled with agents, cloud inventory and directory records
- Re-synced on a schedule, with closure driven by absence from a later run
Credential required
A Qualys API user with read access to the asset groups you name.
What this connector is for
Most organisations running Qualys also run something else — an agent-based scanner, a cloud provider's own findings, a container scanner. Each produces its own count of the same estate, and the counts never agree. Ingesting Qualys here is how its results stop being a separate number and start being part of one.
What is ingested
Confirmed detections against the hosts in the asset groups the connector is configured for, with their QIDs, CVEs, first- and last-seen timestamps and detection status. The timestamps matter: a finding's age is what an SLA is measured against, and taking it from the source rather than from ingestion time is what keeps a re-platformed scanner from resetting every clock in the estate.
What happens next
Detections become findings on reconciled assets, are deduplicated against the same CVE reported elsewhere, and are prioritised on exploitability and asset criticality rather than on severity alone. Remediation is routed to the owning team, tracked against an SLA, and closed only when a later run — or a targeted rescan — no longer sees it.
What you have to grant
An API user with read permission. Nothing is written back to Qualys.