What Changed

The Qualys VM KnowledgeBase CCF connector (QualysKB_PollingConfig.json) received four substantive fixes to address incomplete vulnerability data ingestion:

  1. Query filter changed from published_after/before to last_modified_after/before – The previous filter only captured vulnerabilities by original publication date. Updated or re-scored QIDs (common after vendor patch cycles or CVSS rescoring) were never re-ingested, leaving stale or missing entries in the workspace.

  2. Optional filter parameters removed – show_qid_change_log previously used a dynamic ARM concat expression that appended optional filter strings (is_patchable, discovery_method, discovery_auth_types) when those parameters were populated. When the Qualys API received these as empty strings, it returned HTTP 400 errors, silently dropping the polling request. The value is now hardcoded to 0.

  3. Timeout increased from 30s to 120s – The Qualys KB API returns large payloads for full KB exports. The 30s timeout caused failures on large responses, resulting in partial or no data for that polling window.

  4. Query window reduced from 10 min to 5 min (final tested value after PR discussion) – An intermediate value of 1440 min (24h) was evaluated but caused duplicate ingestion of 5,086 QIDs (avg 2x, max 3x) per cycle due to overlap with the 600-min propagation delay. The 5-min window eliminates re-fetch overlap while the queryWindowDelayInMin: 600 continues to respect Qualys 8-10h data propagation SLA.

Security Impact (Visibility and Fidelity)

Deployments running v3.1.2 and earlier had two distinct ingestion failure modes:

  • HTTP 400 failures: When optional filter parameters (is_patchable, discovery_method, discovery_auth_types) were set, the Qualys API rejected the request entirely – zero records returned for those polling cycles.
  • Modified-record blind spot: Because filtering was on published_after/before, any QID updated after initial publication (e.g., CVSS score changes, vendor patch status changes, detection logic updates) was never re-ingested. Vulnerability queries in Sentinel referencing these QIDs returned stale or missing enrichment data.

The last_modified_after/before switch ensures re-scored or re-classified vulnerabilities are captured. This is particularly relevant for vulnerability prioritisation workflows where CVSS changes affect remediation SLAs.

Per PR discussion: duplicate ingestion testing with a 1440-min window confirmed 5,086 QIDs were being re-ingested at 2-3x frequency, confirming the polling logic was previously broken in a way that would have caused both under-ingestion (HTTP 400 cases) and silent data staleness (publish-date filter).

Affected Files

Solutions/Qualys VM Knowledgebase/Data Connectors/QualysKB_ccf/QualysKB_PollingConfig.json
(packaging artefacts: 3.1.3.zip, ReleaseNotes.md, Solution_QualysKBtemplateSpec.json, mainTemplate.json)