[Bug] Missing Non ECS fields for ES|QL Rules post 6491 merge

[eric-forte-elastic]

Pull Request

Issue link(s):

Summary - What I changed

Small update to fix the non-ecs fields for ES|QL rules as a result of merging #6491.

Needed to update the non-ecs file as well as the index mappings handling for ES|QL now that we have strict validation against ECS fields in integrations to resolve https://github.com/elastic/ia-trade-team/issues/1036

Note

Please review Alt Strategy and Original to decide what one prefers (or propose a different alternative).

How To Test

ES|QL Remote Tests and Unit Tests.

Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[Copilot]

🟡 Changes recommended

Mapping-source handling issues remain, and focused unit coverage is needed.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR restores missing non-ECS fields for ES|QL rules and updates mapping validation after PR #6491.

Changes:

• Bumps the package version to 2.2.6.
• Updates mapping availability checks.
• Adds integration-specific non-ECS field mappings.

File summaries

File	Summary
pyproject.toml	Updates the package version.
detection_rules/index_mappings.py	Adjusts mapping validation handling.
detection_rules/etc/non-ecs-schema.json	Adds integration-specific field mappings.

Review details

Suppressed comments (2)

detection_rules/etc/non-ecs-schema.json:705

• The new non-ECS fields are keyed under logs-system.security-*, but the existing ES|QL Windows rules use the broader FROM logs-system.security* pattern (for example, rules/windows/credential_access_bruteforce_admin_account.toml:115). prepare_mappings first loads non-ECS data with an exact non_ecs.get(index) lookup, so the broader source gets no fields from this block even though later pattern matching sees the narrower key; those rules can still fail strict validation for the fields added here. Add a matching broad schema entry or make the lookup merge every matching non-ECS pattern.

  "logs-system.security-*": {
    "event.action": "keyword",
    "event.category": "keyword",
    "event.code": "keyword",
    "event.created": "date",

detection_rules/index_mappings.py:682

• custom_mapping is another schema source loaded and merged below, but this guard ignores it. In a custom-rules configuration with only an auto-generated custom schema for the queried index, integration_mappings, existing_mappings, non_ecs_schema, and ecs_schema can all be empty while the custom mapping is valid; this raises No mappings found before returning it. Check whether the custom mapping values contain fields as well.

    if not (integration_mappings or existing_mappings or non_ecs_schema or ecs_schema):

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[eric-forte-elastic]

Also adding an alternative strategy, to split the current "non-ecs" fields to 2 separate files: 1) Traditional non-ecs and 2) integration-emited-ecs

One decision point:

• Eight ECS-named fields predate both PRs and remain in the non-ecs file: file.size on endpoint events, and seven http., url.path, network.direction, and data_stream.dataset entries on logs-network_traffic.http. Three have types that conflict with ECS.

I think we should move the ones that do not conflict, but keep the ones that do in non-ecs (what the commit 6fa72a0 does).

But open to alternate ideas too 👍

[bryans3c]

Vote for split too. Only the emitted-ECS half is fixable, so separating it gives you a list you can take to the package owners and shrink, while non-ecs stays permanent. Mixed in one file you can't tell which entries are temporary. Agree on keeping the type-conflicting ones where they are.