elastic / elastic/integrations
[dashboard-data-scope] High-severity unscoped data source in Microsoft Defender Endpoint machine action dashboard
- Dominant language
- Handlebars
- Stars
- 333
- Forks
- 647
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 209
Description
## Findings
### 1. Microsoft Defender Endpoint machine action dashboard uses global `logs-*` as active control and panel data source
**Location**
- `packages/microsoft_defender_endpoint/kibana/dashboard/microsoft_defender_endpoint-6a043fee-1e3d-454b-96d1-159e6efce215.json:15,32` (`"dataViewId": "logs-*"` in control panels)
- `packages/microsoft_defender_endpoint/kibana/dashboard/microsoft_defender_endpoint-6a043fee-1e3d-454b-96d1-159e6efce215.json:137,310,508,661,823,954` (`"id": "logs-*"` in visualization references)
- `packages/microsoft_defender_endpoint/kibana/dashboard/microsoft_defender_endpoint-6a043fee-1e3d-454b-96d1-159e6efce215.json:52-80` (dashboard filter only on `labels.is_transform_source`, no `data_stream.dataset`/`event.module` scoping)
**Evidence**
- Control dropdowns are bound to global logs:
- `"fieldName": "event.action"` with `"dataViewId": "logs-*"`
- `"fieldName": "microsoft_defender_endpoint.machine_action.status"` with `"dataViewId": "logs-*"`
- The dashboard does not enforce integration-level dataset/module scoping in `kibanaSavedObjectMeta.searchSourceJSON`.
**What is wrong**
This dashboard belongs to `microsoft_defender_endpoint` but its active data source is global `logs-*` without package scoping, so controls/visualizations can read unrelated integrations' logs.
**Why it matters**
In clusters with multiple integrations installed, opening this dashboard can surface non-Defender values (especially for generic fields like `event.action`), causing misleading filters and mixed data in machine action panels.
**Suggested fix**
Scope controls and panel references to Defender Endpoint streams, e.g. `logs-microsoft_defender_endpoint.machine_action-*` (and other required `microsoft_defender_endpoint.*` streams as needed), instead of `logs-*`.
## Additional required checks from this audit
- **Stale `indexPatternId` references (new, high-severity):** none confirmed in this package during this run.
- **`SVR00002` suppressed without explanation (new, high-severity):** none confirmed for this package (`packages/microsoft_defender_endpoint/validation.yml` does not suppress `SVR00002`).
## Suggested Actions
- [ ] Replace global `logs-*` control/panel data sources in `microsoft_defender_endpoint-6a043fee-1e3d-454b-96d1-159e6efce215.json` with Microsoft Defender Endpoint scoped patterns.
- [ ] Re-export the dashboard so by-value references and internal Lens state are consistently scoped.
## Audit Coverage
- Total dashboards scanned: **1308**
- Dashboards with confirmed high-severity findings in this report: **1**
> [!NOTE]
>
> 🔒 Integrity filter blocked 1 item
>
> The following item were blocked because they don't meet the GitHub integrity level.
>
> - [#17567](https://github.com/elastic/integrations/issues/17567) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
>
> To allow these resources, lower `min-integrity` in your GitHub frontmatter:
>
> ```yaml
> tools:
> github:
> min-integrity: approved # merged | approved | unapproved | none
> ```
>
>
---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Sweeper: Dashboard Data Scope and Filter Integrity](https://github.com/elastic/integrations/actions/runs/27340739770)
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on Jun 18, 2026, 10:45 AM UTC
Contributor guide
Assessment
This issue has not been assessed yet.