[dashboard-data-scope] High-severity unscoped SentinelOne dashboard controls query global logs-* across all dashboards

## Findings

### 1. SentinelOne dashboard controls use over-broad data sources (`logs-*`) across all package dashboards

**Evidence (actual control data source, not metadata):**

All SentinelOne dashboards under `packages/sentinel_one/kibana/dashboard/` contain options-list controls with:

```json
"dataViewId": "logs-*"
```

Concrete locations:
- `packages/sentinel_one/kibana/dashboard/sentinel_one-0dd17490-bbb8-11ec-82b7-8fcb232e9538.json:15,34`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-413bf268-78f7-4bea-b668-55b5adacbf08.json:15,34`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-5881f5f0-bb2c-11ec-82b7-8fcb232e9538.json:15,41`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-67844880-bbb5-11ec-82b7-8fcb232e9538.json:15,34,53`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-899f2630-bb27-11ec-82b7-8fcb232e9538.json:15,34`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-9d3f16ad-d421-4475-b0e2-c9b3f795e0d5.json:15`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-acd472d9-a6b7-4a53-a58d-06c315764c8d.json:15,34`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-bcf1f680-bba3-11ec-82b7-8fcb232e9538.json:15,34`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-d17089b1-173e-4c17-8830-779346ace39d.json:15,34,53,72,91,110`

Dashboard-level search sources are unscoped (empty filter/query), e.g.:
- `packages/sentinel_one/kibana/dashboard/sentinel_one-413bf268-78f7-4bea-b668-55b5adacbf08.json:57` → `"filter": []`
- `packages/sentinel_one/kibana/dashboard/sentinel_one-413bf268-78f7-4bea-b668-55b5adacbf08.json:60` → `"query": ""`

**Correct package scope exists and should be used:**
- SentinelOne data streams are `type: logs` (e.g. `packages/sentinel_one/data_stream/*/manifest.yml:2`)
- Package stream ILM names show scoped patterns like `logs-sentinel_one.-*` (e.g. `packages/sentinel_one/data_stream/application/manifest.yml:3`, `.../application_risk/manifest.yml:3`, `.../unified_alert/manifest.yml:3`, `.../threat_event/manifest.yml:3`)

**What is wrong:**
Control dropdowns query global `logs-*` instead of SentinelOne-scoped data views. In multi-integration clusters, controls resolve values from unrelated integrations.

**Why it matters (high severity):**
This is immediately user-visible in every SentinelOne dashboard: control values (host/user/group/event fields) include unrelated data, so filtering can drive panels to non-SentinelOne documents and produce misleading dashboard analysis.

**Action needed / suggested fix:**
1. Replace control `dataViewId: "logs-*"` with SentinelOne-scoped data views (`logs-sentinel_one.*-*`, or dataset-specific scoped views per dashboard/panel).
2. Keep dashboard/panel queries aligned to SentinelOne datasets to prevent cross-integration leakage.
3. Regenerate/export dashboards after scoping changes so all control definitions are consistently scoped.

## Duplicate check

This finding is distinct from currently open dashboard-data-scope issues:
- #18065 (Azure OpenAI, AWS ELB OTEL, Proofpoint)
- #18200 (Gigamon stale indexPatternId)
- #18306 (macOS and Microsoft SQL Server OTel)

## Audit coverage

- Total dashboards scanned: **1263**
- Dashboards with confirmed new findings in this report: **9** (all SentinelOne dashboards)

---
[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/24502929049)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on Apr 23, 2026, 9:55 AM UTC