Skip to content

[Enhancement] Set event.kind to alert for AWS GuardDuty findings#18895

Open
bryans3c wants to merge 5 commits intomainfrom
aws-guardduty-event-kind-alert
Open

[Enhancement] Set event.kind to alert for AWS GuardDuty findings#18895
bryans3c wants to merge 5 commits intomainfrom
aws-guardduty-event-kind-alert

Conversation

@bryans3c
Copy link
Copy Markdown

@bryans3c bryans3c commented May 8, 2026

Proposed commit message

Set `event.kind` to `alert` for the AWS GuardDuty findings. ​

Summary

This sets event.kind to alert in AWS GuardDuty events, so that the default external alert promotion detection rule in elastic/detection-rules matches GuardDuty findings and surfaces them on the Alerts page. Currently the pipeline sets event.kind: event, which causes the promotion rule to silently skip GuardDuty data despite the integration being installed.

Same pattern as #16401 (Wiz Defend) and #5744 (M365D incidents).

Why this is safe

The aws.guardduty data stream is finding-only by API contract:

  • The data stream manifest configures two inputs (httpjson and aws-s3), both titled "Collect Amazon GuardDuty Findings from AWS."
  • httpjson polls AWS's GuardDuty Findings API (ListFindings/GetFindings), which returns findings only.
  • aws-s3 ingests GuardDuty findings exports, which contain findings only.
  • Neither input can deliver any other event type into this stream.

This is the key difference from #10528 (F5 BIG-IP ASM), where a single dataset legitimately mixed informational and alert events and unconditional event.kind: alert mislabeled the informational ones. There is no equivalent informational subset in aws.guardduty to mislabel.

The two existing GuardDuty-related detection rules in elastic/detection-rules (defense_evasion_guardduty_detector_deletion and defense_evasion_guardduty_member_manipulation) detect tampering with the GuardDuty service itself via CloudTrail (DeleteDetector, DisassociateMembers, etc.) and query logs-aws.cloudtrail-*, not logs-aws.guardduty-*. They are unaffected by this change.

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.
  • I have verified that any added dashboard complies with Kibana's Dashboard good practices

@bryans3c bryans3c requested review from a team as code owners May 8, 2026 09:10
@bryans3c bryans3c added enhancement New feature or request Integration:aws AWS Team:Security-Service Integrations Security Service Integrations team [elastic/security-service-integrations] labels May 8, 2026
@infra-vault-gh-plugin-prod
Copy link
Copy Markdown

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

@github-actions

This comment has been minimized.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 8, 2026

✅ Vale Linting Results

No issues found on modified lines!


The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 8, 2026

TL;DR

Check integrations aws failed in Buildkite #42560, but the available log artifact only includes teardown output and a generic exit status 1, so the actual failing check is not visible. The immediate next step is to retrieve the full failed step output (or the failing test/check artifact) and rerun triage on that data.

Remediation

  • Re-run Check integrations aws with full step output retained (especially the section before --- [aws] failed) and share that log.
  • If available, inspect/upload the failing artifact from that run (for example the failing build/test-results/*.xml entry) and include the exact failing test/check name and message.
Investigation details

Root Cause

Inconclusive with current data. The pre-fetched log at /tmp/gh-aw/buildkite-logs/integrations-check-integrations-aws.txt does not include the failing command/test output, only cleanup and a generic failure marker.

Evidence

  • Build: https://buildkite.com/elastic/integrations/builds/42560
  • Job/step: Check integrations aws
  • Key log excerpt:
    --- [aws] failed
    🚨 Error: The command exited with status 1
    user command error: exit status 1
    
  • The same file then immediately shows artifact upload + stack teardown logs, with no preceding assertion/lint/test failure text.

Verification

  • Not run end-to-end locally in this workflow because CI bootstrap variables/tools required by .buildkite/scripts/test_one_package.sh are not available in this environment.

Follow-up

Once the full failed step output is available, I can map it directly to the owning file/line and provide a precise fix recommendation.


What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

@elasticmachine
Copy link
Copy Markdown

elasticmachine commented May 9, 2026

💔 Build Failed

Failed CI Steps

History

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request Integration:aws AWS Team:Security-Service Integrations Security Service Integrations team [elastic/security-service-integrations]

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants