[Contextual Security] SIEM Readiness Coverage All Rules Bug Fix#249923
[Contextual Security] SIEM Readiness Coverage All Rules Bug Fix#249923animehart merged 12 commits intoelastic:mainfrom
Conversation
|
/ci |
1 similar comment
|
/ci |
|
Pinging @elastic/contextual-security-apps (Team:Cloud Security) |
|
/ci |
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug in the SIEM Readiness Coverage All Rules panel where installed integrations were incorrectly displayed even when there were zero enabled rules. The fix ensures that only integrations related to enabled rules are shown in the installed/missing integrations lists.
Changes:
- Modified integration filtering logic to derive installed/missing integrations from enabled rules rather than purely from the packages API
- Added memoized computation to extract integrations from enabled rules and compare with installed packages
- Updated type definition to include
enabledfield inRelatedIntegrationRuleResponse
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| x-pack/solutions/security/plugins/security_solution/public/siem_readiness/pages/tabs/coverage_tab/rule_coverage_panels/all_rules.tsx | Refactored integration filtering to only include integrations from enabled rules, replacing direct usage of installedIntegrationRules coverage data |
| x-pack/solutions/security/packages/siem-readiness/src/types.ts | Added enabled field to RelatedIntegrationRuleResponse type definition |
| } | ||
|
|
||
| export interface RelatedIntegrationRuleResponse { | ||
| enabled: { package: string; version?: string; integration?: string }[] | undefined; |
There was a problem hiding this comment.
The enabled field appears to be misplaced in the type definition. Based on the usage in all_rules.tsx where rule.enabled is accessed as a boolean and rule.related_integrations is accessed as an array, the enabled field should be a boolean property at the same level as related_integrations, not an array of integration objects. The current definition suggests enabled contains integration data rather than representing the rule's enabled state.
| enabled: { package: string; version?: string; integration?: string }[] | undefined; | |
| enabled: boolean; |
| const integrationsFromEnabledRules = useMemo(() => { | ||
| if (!getDetectionRules.data?.data || getDetectionRules.data.data.length === 0) { | ||
| return { | ||
| relatedIntegrationNames: [], | ||
| installedIntegrationNames: [], | ||
| }; | ||
| } | ||
|
|
||
| const integrationsSet = new Set<string>(); | ||
|
|
||
| getDetectionRules.data.data.forEach((rule) => { | ||
| if (rule.enabled && rule.related_integrations) { | ||
| rule.related_integrations.forEach((integration) => { | ||
| if (integration.package) { | ||
| integrationsSet.add(integration.package); | ||
| } | ||
| }); | ||
| } | ||
| }); | ||
|
|
||
| return { | ||
| relatedIntegrationNames: Array.from(integrationsSet), | ||
| installedIntegrationNames: getInstalledIntegrations.map((item) => item.name), | ||
| }; | ||
| }, [getDetectionRules.data?.data, getInstalledIntegrations]); |
There was a problem hiding this comment.
The new logic for filtering integrations from enabled rules lacks test coverage. This is critical functionality that determines which integrations are displayed as installed or missing. Tests should verify: (1) integrations are correctly extracted from enabled rules only, (2) disabled rules are properly excluded, (3) the intersection logic between related and installed integrations works correctly, and (4) edge cases like rules without related_integrations are handled.
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Public APIs missing comments
Async chunks
History
|
Summary
This PR is to address the Fix for the recently merged SIEM Readiness All Rules panel where Installed integration shows up when there are 0 Enabled Rules
This Issue was caused because the Installed integration was purely from packages API. We instead should be comparing those result with the list of related_integrations we get from the rules
** Before **
** After **
