Vulnerabilities are active in Qualys but there are no open VIT records in VR for those detections.

[yashwanth8]

Vulnerabilities are active in Qualys for below CI's but there are no open VIT records for those detections.

• We have active vulnerabilities in Qualys for certain CIs, but there are no open VIT records for those detections. This issue started recently—previously, VIT records were created for these Qualys IDs. Could this be related to a recent upgrade? Were there any code changes introduced that might ignore these records?

• If this is not due to the upgrade, is there any out-of-the-box (OOB) logic in ServiceNow VR that could prevent VIT record creation for certain Qualys detections?

[MaxMixali]

ServiceNow Vulnerability Response (VR) – Qualys detections present but no VITs created

Problem
You see active vulnerabilities in Qualys for certain CIs, but ServiceNow is not creating Vulnerable Item Tasks (VITs) anymore. This used to work. You’re asking whether a platform/app upgrade or OOB logic could be suppressing VIT creation.

Short answer
Yes—there are several out‑of‑the‑box (OOB) gates that can prevent creation of Vulnerable Items (VI) and their VITs, even when detections are imported. An upgrade (platform or Store app) can also change transform/ingest behavior, default properties, or pipelines. Use the checklist below to identify which gate is blocking creation.

Key concepts (VR data path)
1) Source ingest (Qualys) → raw/staging tables (source-specific)
2) Processing/transform → Vulnerable Item (VI)
3) Grouping/assignment → Vulnerability Group & VIT(s)
A break at any stage stops VIT creation even if detections exist upstream.

Most common OOB reasons VITs are not created
1) CI matching / “require CI” gate
- If the Qualys asset cannot be matched to a CMDB CI (no IP/hostname/serial match), OOB settings can drop the VI instead of creating it without a CI. Many orgs enable “create only when CI is found.”
- Recent CMDB changes (e.g., retired CIs, duplicate IPs) can increase “no match” rates.
2) Severity / status filters
- Ingest filters that exclude detections below a severity threshold or detections not in “Active/Confirmed” status will skip VI creation.
- If Qualys status mapping changed (e.g., reclassified as Ignored/Fixed) they are filtered out.
3) Suppression / exception rules
- Global or source-specific suppression rules (e.g., for specific QIDs/CVEs, tags, business units) prevent VI creation or immediately close VIs.
- Approved exceptions at VI/CVE/CI level can stop re-creation or reopen.
4) De‑duplication / re-open logic
- If a VI exists historically and was closed with a terminal state (e.g., “Risk accepted” / “False positive”), OOB re‑open behavior may be disabled. The new detection is ignored instead of reopening.
5) Transform/ingest schema drift
- After an upgrade (platform or Qualys VR app), the source column names/aliases can change. If the transform map or pipeline still expects the old schema, records fail downstream while “Test” appears fine.
6) Assignment / task creation disabled
- VIs may still be created, but VIT creation is disabled by rule (e.g., only create tasks for critical/high groups; or create on demand). Verify whether VIs exist but VITs do not.
7) Job/MID differences
- The “Test” in a dev tool uses a different MID Server or account that sees different data/columns than the scheduled job. Runtime then fails the mapping or filtering.

Upgrade-related items to verify
- App versions: Qualys integration and VR Store app versions changed? Review their release notes for ingest pipeline, field, or property changes.
- Properties reset: Vulnerability > Administration > Properties—check severity thresholds, CI-required toggles, suppression behavior, reopen settings.
- Pipelines vs Transform Maps: Newer releases use ingestion pipelines (source-agnostic). Ensure the correct processor is active and ordered ahead of any legacy maps.
- Scripted business rules: Some customers added “guard” rules that silently skip VIs unless CI/Severity conditions are met. These are often re-enabled by update sets after upgrade.

Step-by-step triage (fast path)
1) Confirm ingest:
- Check the latest Qualys import runs and raw/staging tables (source-specific) to verify the detections arrived.
- Spot-check a QID/CVE that is missing a VIT and confirm it is in staging.
2) Check VI creation:
- Search for a Vulnerable Item (VI) by CI + QID/CVE. If no VI, the break is in ingest/transform or a gate (CI match, suppression, severity).
- If VI exists but no VIT, the break is at grouping/assignment or task creation rules.
3) CI matching:
- Validate the CI is active, not retired, has current IP/hostname.
- Review any “CI required”/“Only create when matched” property or filter.
4) Suppression / exceptions:
- Check suppression rules and exceptions for that QID/CVE/CI (global and source-specific). Temporarily disable to test.
5) Severity / source status filters:
- Validate severity threshold and detection status mapping (Active/Confirmed only?). Check the exact fields coming from Qualys in staging.
6) Schema/transform:
- Compare staging column names against your transform/pipeline field mappings. Re-generate/migrate mappings if a column changed. Avoid relying on “Test” only; check Transform History for row-level errors.
7) VIT creation rules:
- Review Vulnerability Grouping and Task Creation rules. Ensure rules aren’t limited to Critical/High only, or specific assignment groups.
😎 Reopen logic:
- Inspect the historical VI state. If it was closed as risk accepted/FP, verify properties that control re-open on new detections (some orgs set “never re-open terminals”).

Quick remediation patterns
- Turn off “require CI match” temporarily to verify if the gate is CI matching.
- Lower severity threshold to test creation (then restore).
- Disable suppression temporarily to confirm if a rule is swallowing records.
- Re-run transform/ingest after updating mappings, and validate Transform History shows creates, not ignores.
- If only VITs are missing, enable/adjust “auto create task” rule and grouping thresholds.

Data points to capture for a supportable RCA
- One example Qualys Asset + Detection (QID/CVE) with timestamps
- Staging row content (all fields)
- Transform History entry for that row
- VI search result (present/missing)
- Current CI record used for matching
- Screenshots of Properties (severity threshold, CI requirement), suppression/exception rules
- App versions (VR core + Qualys integration)

TL;DR
Yes—this often comes down to OOB gates: CI matching required, suppression/exception rules, severity/status filters, or task creation rules. Upgrades can change mappings or defaults. Walk the ingest → VI → VIT path, verify the gates, and adjust properties or mappings to restore creation.

[Martin Dewit]

Thanks ChatGPT!