[Attack Discovery][Scheduling] Improved duplicates logging

[e40pud]

Summary

Main ticket (Internal link)

With these changes we improve the attack discovery alerts duplicates logging.

Info level logging examples

Manually generated:

Ad-hoc Attack Discovery: Found 1 duplicate alert(s), skipping report for those.

Scheduled generations:

Attack Discovery Schedule: Found 1 duplicate alert(s), skipping report for those.

Additional debug level logging examples

Manually generated:

Ad-hoc Attack Discovery: Duplicated alerts:
[
  "{{attack-discovery-alert-id}}"
]

Scheduled generations:

Attack Discovery Schedule: Duplicated alerts:
[
  "{{attack-discovery-alert-id}}"
]

To Test

1. Create Attack Discovery Schedule which runs over the same alerts multiple time (for example set alerts query time to 24h)
2. Wait until schedule runs several times and produces duplicated attack discoveries
3. Check kibana server logs

Example of logging

NOTES

The feature is hidden behind the feature flag (in kibana.dev.yml):

feature_flags.overrides:
  securitySolution.attackDiscoveryAlertsEnabled: true
  securitySolution.assistantAttackDiscoverySchedulingEnabled: true

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[andrew-goldstein]

Consider replacing the isSchedule: boolean:

interface DeduplicateAttackDiscoveriesParams {
  // ...
  isSchedule: boolean;
}

with something like:

interface DeduplicateAttackDiscoveriesParams {
  // ...
  scheduleId: string | undefined;
}

such that the executor in x-pack/solutions/security/plugins/elastic_assistant/server/lib/attack_discovery/schedules/register_schedule/executor.ts can pass scheduleInfo.id

    const dedupedDiscoveries = await deduplicateAttackDiscoveries({
      esClient,
      // ...
      scheduleId: scheduleInfo?.id,
    });

to enable logging the schedule id here:

    const logPrefix =
      scheduleId != null ? `Attack Discovery Schedule [${scheduleId}]` : 'Ad-hoc Attack Discovery';

The example above looks like this when logged:

[2025-07-11T12:41:37.739-04:00][INFO ][plugins.elasticAssistant] Attack Discovery Schedule [4c871930-624c-4fcf-a999-94126fe8d65d]: Found 2 duplicate alert(s), skipping report for those.

[e40pud]

We already have ownerId which is either username/user profile ID (in case of manual generation) or rule ID (in case of schedules). One thing which is missing is the notion what type of execution it is - manual vs scheduled.

I will convert ownerId in an object that will contain both, something like:

ownerInfo: {
  id: string; // username/profileId OR ruleId
  isSchedule: boolean; // whether it is a scheduled run
}

Then if it is a schedule, I will add ruleId in the log.

[e40pud]

Done in b952c14

[andrew-goldstein]

Thanks @e40pud for the improved logging!
✅ Desk tested locally
LGTM 🚀

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 5449d01

Metrics [docs]

✅ unchanged

History

• 💛 Build #318649 was flaky b952c14
• 💚 Build #318264 succeeded 2142295

cc @e40pud

[kibanamachine]

Starting backport for target branches: 8.19, 9.1

https://github.com/elastic/kibana/actions/runs/16270829330

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.19
✅	9.1

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation