Qualys VMDR

RAD Security connects directly to the Qualys VMDR APIs with a Qualys API user and pulls three objects into three dedicated data types: host detections, host assets and the QID KnowledgeBase.

The data keeps Qualys' vocabulary. Severity stays the Qualys 1–5 grade, status stays New / Active / Fixed / Re-Opened, and a detection keeps Qualys' own grain. Nothing is re-scored or re-labelled on the way in, so a number in RAD and the same number in the Qualys console are answering the same question.

Prerequisites

What RAD stores

The three types are queryable in the Evidence Room, in dashboard widgets, through the data API and through radbot, the same way any other RAD data type is.

---

Step 1: Create the API user in Qualys

KnowledgeBase access

The KnowledgeBase download API is a per-subscription grant, separate from the user's role. If it is not granted, Qualys answers the KnowledgeBase call with HTTP 403 while the detection calls succeed.

RAD's verification step reports this case explicitly rather than as a credential failure. If you see it, ask Qualys Support to enable the KnowledgeBase download API for your subscription. Without it, detections still sync, but the title, category, CVE list, threat indicators and CVSS scores stay empty.

---

Step 2: Find your API Server URL

Qualys publishes two different hostnames per platform. This integration uses the API Server URL (qualysapi.…), not the API Gateway URL (gateway.…).

---

Step 3: Configure in RAD Security

Open Data Sources > Integrations > Vulnerabilities, add the Qualys VMDR integration and fill in three fields.

The URL must use https. The credentials travel as HTTP Basic authentication on every call, so plain http is rejected before anything leaves RAD.

What verification does

Saving the integration spends two to three Qualys API calls:

1. Version negotiation — RAD probes the Host List Detection endpoint from version 6.0 downwards and pins the highest version your subscription serves.
2. Detection probe — a one-host detection page, parsed end to end. This proves the credentials, the URL and the response pipeline together.
3. KnowledgeBase probe — a single QID. This proves the subscription grant described above, not data presence.

The negotiated versions are pinned onto the integration and shown on the configured card alongside the POD URL. They are re-negotiated only if you change the POD API Server URL.

---

Reading the data

Open is a column, not a status

A detection is open when is_open = 1. That single column is the answer to "how many open vulnerabilities do we have", on every surface: Evidence Room filters, dashboard widgets, the data API and radbot.

is_open = 1 means all of the following hold:

• status is New, Active or Re-Opened
• is_ignored = 0 and is_disabled = 0
• absence_reason is empty

Everything else — Fixed, ignored, disabled, a detection whose host was purged from Qualys, a detection that stopped being reported — reads is_open = 0.

Qualys vocabulary is kept verbatim

Severity is not RAD-normalized. severity:5 is Qualys' Urgent, severity:4 is Qualys' Critical, and they are distinct — see the severity crosswalk if you are migrating queries or dashboards that used RAD's normalized bands.

One row per detection, and what a detection is

Qualys identifies a detection by host, QID, port, protocol, SSL flag, FQDN and service. Two findings of the same QID on the same host over different ports are two detections in Qualys, and two rows in RAD.

Each row is the current state of that detection. RAD stores every observation as a version and reads back the latest one, so a query never sees a superseded version and a closure supersedes the open row immediately.

KnowledgeBase is a second query

Each detection row carries the KnowledgeBase attributes needed to filter and list — title, category, CVEs, threat indicators, patchable flag, CVSS base scores — copied onto the row and refreshed on every re-observation.

The long prose (diagnosis, consequence, solution) is not copied. Query qualys_knowledge_base by qid when you need it.

Measuring remediation time

ttr_days is written when a detection closes: the number of days between Qualys' FIRST_FOUND_DATETIME and LAST_FIXED_DATETIME.

• Compute MTTR as avg(ttr_days), filtered to status:Fixed over a Last Fixed window.
• Detections that are not closed leave ttr_days empty, and empty values are excluded from the average rather than counted as zero.
• A closure that Qualys reports without a LAST_FIXED_DATETIME also leaves it empty. RAD does not substitute the observation date, because a guessed zero is indistinguishable from a genuine same-day fix.

The 90-day closure horizon

Queries reach back 90 days from the Qualys clock you filter on. first_found_datetime, last_found_datetime and last_fixed_datetime all widen the window for you, so "found this quarter" and "fixed this quarter" work.

Beyond 90 days they do not. "Everything we fixed last year" and year-over-year MTTR trends are out of reach of the query surfaces; the underlying storage keeps the full history and RAD support can query it directly.

---

Sync cadence and API budget

A pass that cannot finish within its cycle stops on a cursor and resumes on the next one, so no cycle occupies your API quota indefinitely.

RAD reads the X-RateLimit-* and concurrency headers Qualys returns on every call and holds itself to one concurrent request. It stops spending as soon as your remaining allowance reaches a 20% reserve of the observed rate-limit window, and resumes on a later cycle — so a fifth of the window is always left for your own automation against the same subscription.

---

Known limitations

---

Troubleshooting

---

Next Steps