Multiple Vulnerabilities by Asset via Wiz

This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2026/01/22"
 3integration = ["wiz"]
 4maturity = "production"
 5updated_date = "2026/01/22"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture,
11missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable
12vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk.
13"""
14from = "now-24h"
15interval = "5m"
16language = "esql"
17license = "Elastic License v2"
18name = "Multiple Vulnerabilities by Asset via Wiz"
19note = """## Triage and analysis
20
21> **Disclaimer**:
22> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
23
24### Investigating Multiple Vulnerabilities by Asset via Wiz
25
26This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk.
27
28### Possible investigation steps
29
30- Review the affected asset details using `wiz.vulnerability.vulnerable_asset.name` and `wiz.vulnerability.vulnerable_asset.id` to confirm asset ownership, criticality, and exposure (e.g., internet-facing, production).
31- Examine the list of detected vulnerabilities using `Esql.vuln_id_values` to identify known high-risk or widely exploited CVEs.
32- Assess vulnerability severity distribution via `Esql.vuln_severity_values`, focusing on assets with multiple severity levels or repeated high/critical findings.
33- Determine whether any vulnerabilities have known exploits by validating `wiz.vulnerability.has_exploit`, prioritizing those assets for immediate remediation.
34- Cross-check recent patching, configuration changes, or deployment activity on the asset to identify potential gaps or misconfigurations.
35
36### False positive analysis
37
38- Assets undergoing initial onboarding, scanning expansion, or configuration changes may temporarily report a high volume of findings.
39- Vulnerability aggregation may include informational or low-impact findings that inflate counts without representing immediate risk.
40- Duplicate or closely related vulnerabilities affecting shared packages or libraries may appear as multiple findings for the same root cause.
41- Test, lab, or non-production assets may legitimately tolerate higher vulnerability counts depending on risk acceptance.
42
43### Response and remediation
44
45- Prioritize remediation for assets with exploitable vulnerabilities or multiple high/critical severity findings.
46- Apply missing patches, updates, or configuration fixes according to asset criticality and exposure.
47- Implement compensating controls (e.g., network segmentation, access restrictions) if immediate patching is not feasible.
48- Validate remediation by re-scanning the asset in Wiz to confirm vulnerability reduction.
49- Review vulnerability management processes to prevent recurrence, including patch SLAs, asset ownership, and exposure monitoring."""
50risk_score = 99
51rule_id = "6fcb4fe4-ac74-449d-855b-2bbd5c51c476"
52severity = "critical"
53tags = ["Use Case: Vulnerability", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide", "Data Source: Wiz"]
54timestamp_override = "event.ingested"
55type = "esql"
56
57query = '''
58FROM logs-wiz.vulnerability-*
59
60| WHERE event.dataset == "wiz.vulnerability" and event.category == "vulnerability" and
61        wiz.vulnerability.vulnerable_asset.name is not null and
62        wiz.vulnerability.vulnerable_asset.id is not null
63| stats Esql.count_distinct_vuln_id = COUNT_DISTINCT(wiz.vulnerability.id),
64        Esql.count_distinct_vuln_severity = COUNT_DISTINCT(wiz.vulnerability.cvss_severity),
65        Esql.count_has_exploit = COUNT(wiz.vulnerability.has_exploit),
66        Esql.vuln_id_values = VALUES(wiz.vulnerability.id),
67        Esql.vuln_severity_values = VALUES(wiz.vulnerability.cvss_severity) by wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id
68| eval concat_vuln_severity_values = MV_CONCAT(Esql.vuln_severity_values, ",")
69| where Esql.count_distinct_vuln_id >= 10 or
70        (Esql.count_has_exploit >= 1 and Esql.count_distinct_vuln_id >= 3) or
71        (concat_vuln_severity_values like "*High*" and Esql.count_distinct_vuln_id >= 3) or
72        (concat_vuln_severity_values like "*Critical*" and Esql.count_distinct_vuln_id >= 3)
73| Keep wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id, Esql.*
74'''
75references = ["https://www.elastic.co/docs/reference/integrations/wiz#vulnerability"]

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Multiple Vulnerabilities by Asset via Wiz

This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk.

Possible investigation steps

  • Review the affected asset details using wiz.vulnerability.vulnerable_asset.name and wiz.vulnerability.vulnerable_asset.id to confirm asset ownership, criticality, and exposure (e.g., internet-facing, production).
  • Examine the list of detected vulnerabilities using Esql.vuln_id_values to identify known high-risk or widely exploited CVEs.
  • Assess vulnerability severity distribution via Esql.vuln_severity_values, focusing on assets with multiple severity levels or repeated high/critical findings.
  • Determine whether any vulnerabilities have known exploits by validating wiz.vulnerability.has_exploit, prioritizing those assets for immediate remediation.
  • Cross-check recent patching, configuration changes, or deployment activity on the asset to identify potential gaps or misconfigurations.

False positive analysis

  • Assets undergoing initial onboarding, scanning expansion, or configuration changes may temporarily report a high volume of findings.
  • Vulnerability aggregation may include informational or low-impact findings that inflate counts without representing immediate risk.
  • Duplicate or closely related vulnerabilities affecting shared packages or libraries may appear as multiple findings for the same root cause.
  • Test, lab, or non-production assets may legitimately tolerate higher vulnerability counts depending on risk acceptance.

Response and remediation

  • Prioritize remediation for assets with exploitable vulnerabilities or multiple high/critical severity findings.
  • Apply missing patches, updates, or configuration fixes according to asset criticality and exposure.
  • Implement compensating controls (e.g., network segmentation, access restrictions) if immediate patching is not feasible.
  • Validate remediation by re-scanning the asset in Wiz to confirm vulnerability reduction.
  • Review vulnerability management processes to prevent recurrence, including patch SLAs, asset ownership, and exposure monitoring.

References

Related rules

to-top