Security 8.19.23 release notes - #7206
Conversation
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
A documentation preview will be available soon. Request a new doc build by commenting
If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here. |
|
This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again. |
dplumlee
left a comment
There was a problem hiding this comment.
Left a question for my own curiosity, content lgtm @nastasha-solomon!
| [[bug-fixes-8.19.23]] | ||
| ==== Fixes | ||
| * Fixes an issue where Attack Discovery didn't automatically select a connector when multiple were available, which disabled **Run** and caused attack discovery generation to fail with a "No model selected" error ({kibana-pull}293656[#293656]). | ||
| * Fixes an issue where detection rule failures caused by an invalid IP field query (such as a wildcard or literal value against an `ip` field) were classified as framework errors, which caused them to count against SLO dashboards ({kibana-pull}291256[#291256]). |
There was a problem hiding this comment.
I'm curious what our standard is for reporting/including things like these in the release notes where it's mostly a fix for internal reasons (SLO dashboards) and customers would theoretically not see any difference on their side of things. Not saying it's wrong to include or anything, I'm assuming this is going off the release_note tag but mostly just wondering if there's a defined best practice we have.
There was a problem hiding this comment.
Good question, and you're correct in that PRs with a non-skip release_note label are included in release notes. To see the full set of criteria that's considered, click on the expandable accordion in this section titled "How are labels used to categorize generated release notes?"
RE your question about release-noting PRs that make internal fixes:
I couldn't find explicit guidance for handling PRs like 291256, which help users avoid future rule failures (if I'm understanding the PR description correctly). For this case, I'd recommend using your best judgement on whether it should be included in the patch release notes. If you'd prefer to keep it in, here's a slightly-revised version of the PR summary that's more relevant to users:
| * Fixes an issue where detection rule failures caused by an invalid IP field query (such as a wildcard or literal value against an `ip` field) were classified as framework errors, which caused them to count against SLO dashboards ({kibana-pull}291256[#291256]). | |
| * Fixes an issue where detection rule failures caused by an invalid IP field query (such as a wildcard or literal value against an `ip` field) were incorrectly classified as rule execution errors ({kibana-pull}291256[#291256]). |
Summary
Fixes elastic/docs-content#8561.
docs/release-notes/8.19.asciidoc(plus the TOC entry indocs/release-notes.asciidoc), converted from the Kibana release notes generator output using thedocs-kibana-release-notesskill.elastic/kibanafor the numbered items to verify accuracy; wording matches the phrasing already reviewed for the parallel 9.4.8 backport (Security 9.4.8 release notes docs-content#8613), and unlinked {elastic-defend} items were taken from the raw tool output (including its expanded descriptions where provided).Notes for reviewers
docs/release-notes/8.19.asciidocline 16). Excluded it here to avoid a duplicate entry — worth confirming this was actually already released in 8.19.22 and not a backport timing mixup.exec, Kafka delivery-report logging, diagnostics bundle relocation, Call Stack Attribution DLL naming, Quark/eBPF probe check, quarantine file hardening, MalwareScore on-disk scan) have no PR numbers in the raw input and weren't independently verified against a PR.Previews