[SIEM] Added graph visualization to entity's flyout

[kfirpeled]

Summary

Adds visualization section to host, user and service entity flyout.

How to test this PR:

• Enable entity store v2
• Load mocked org-data using security-documents-generator
• You should be able to open the entity flyout and see the graph's visualization

Storybooks:

• Host panel
• User panel

Out of scope:

• Generic entity flyout

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• Flaky Test Runner was used on any tests changed

[kibanamachine]

• Storybooks Preview

[albertoblaz]

A few non-blocking comments

[albertoblaz]

I think we should also propagate this field in entity_actions_button.tsx to have a similar behavior when updating filters from the flyout section

[kfirpeled]

agreed, right now I couldn't have a use case where we have grouped entities

I'll continue to explore

[albertoblaz]

I love these helpers, I also suffered when changing this block with all the escaping etc.

I'd just make the delimiters and function names less verbose. I miss a helper for adding nested field such as "\\"entity\\" or "\\"host\\":" and another one for conditionally adding fields like the "host" inner object. But could be refactored in a separate PR

[albertoblaz]

For a separate PR: I would extract lines 304-333 into an auxiliary function to build the docData and keep the main function lean

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[macroscopeapp]

🟡 Medium hooks/use_open_entity_preview_panel.ts:57

isEngineMetadataExist is set to !!entity, which always evaluates to true because entity is a required parameter already dereferenced on line 23. The caller in EntityActionsButton previously passed !!item.entity.availableInEntityStore to indicate whether entity metadata exists in the store. Consider using !!entity.availableInEntityStore to preserve the intended semantics.

Suggested change

	isEngineMetadataExist: !!entity,
	isEngineMetadataExist: !!entity.availableInEntityStore,

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file x-pack/solutions/security/packages/kbn-cloud-security-posture/graph/src/components/graph_grouped_node_preview_panel/hooks/use_open_entity_preview_panel.ts around line 57:

`isEngineMetadataExist` is set to `!!entity`, which always evaluates to `true` because `entity` is a required parameter already dereferenced on line 23. The caller in `EntityActionsButton` previously passed `!!item.entity.availableInEntityStore` to indicate whether entity metadata exists in the store. Consider using `!!entity.availableInEntityStore` to preserve the intended semantics.

Evidence trail:
x-pack/solutions/security/packages/kbn-cloud-security-posture/graph/src/components/graph_grouped_node_preview_panel/hooks/use_open_entity_preview_panel.ts:22 (function signature shows entity as required), :23 (entity dereferenced), :57 (isEngineMetadataExist: !!entity). Commit c5cc04a2010f324a9fb3abc5223d2ad977c68935 shows the previous behavior in entity_actions_button.tsx used `isEngineMetadataExist: !!item.availableInEntityStore`.

[macroscopeapp]

🟢 Low graph_grouped_node_preview_panel/graph_grouped_node_preview_panel.stories.tsx:100

When firstItem.entity?.type is undefined, the template literal coerces it to the string "undefined", producing "undefineds" which capitalizes to "Undefineds". Since this is truthy, the || 'Entities' fallback never executes and users see "Undefineds" instead of "Entities".

-    groupedItemsType = capitalize(`${firstItem.entity?.type}s`) || 'Entities';
+    groupedItemsType = capitalize(`${firstItem.entity?.type || 'entity'}s`) || 'Entities';

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file x-pack/solutions/security/packages/kbn-cloud-security-posture/graph/src/components/graph_grouped_node_preview_panel/graph_grouped_node_preview_panel.stories.tsx around line 100:

When `firstItem.entity?.type` is `undefined`, the template literal coerces it to the string `"undefined"`, producing `"undefineds"` which capitalizes to `"Undefineds"`. Since this is truthy, the `|| 'Entities'` fallback never executes and users see "Undefineds" instead of "Entities".

Evidence trail:
x-pack/solutions/security/packages/kbn-cloud-security-posture/graph/src/components/graph_grouped_node_preview_panel/graph_grouped_node_preview_panel.stories.tsx lines 95-101 (at REVIEWED_COMMIT). Line 100 shows `groupedItemsType = capitalize(`${firstItem.entity?.type}s`) || 'Entities';`. Lines 95-96 show the capitalize function: `const capitalize = (str: string) => !str ? '' : str[0].toUpperCase() + str.slice(1).toLowerCase();`. JavaScript template literal coercion of undefined to string "undefined" is standard ECMAScript behavior.

[kibanamachine]

Flaky Test Runner Stats

🎉 All tests passed! - kibana-flaky-test-suite-runner#11380

[✅] x-pack/solutions/security/test/cloud_security_posture_api/config.ts: 25/25 tests passed.
[✅] x-pack/solutions/security/test/cloud_security_posture_functional/group5/config.ts: 25/25 tests passed.
[✅] x-pack/solutions/security/test/cloud_security_posture_api/config.graph_basic.ts: 25/25 tests passed.
[✅] x-pack/solutions/security/test/serverless/functional/configs/config.cloud_security_posture.essentials.ts: 25/25 tests passed.
[✅] x-pack/solutions/security/test/serverless/functional/configs/config.cloud_security_posture.complete.ts: 25/25 tests passed.
[✅] x-pack/solutions/security/test/serverless/functional/configs/config.cloud_security_posture.basic.ts: 25/25 tests passed.

see run history

[albertoblaz]

Isn't this hook a duplication of x-pack/solutions/security/plugins/security_solution/public/flyout/document_details/shared/hooks/use_graph_preview.ts ?

[CAWilson94]

LGTM 🚀 @elastic/security-entity-analytics

Reviewed files owned by Entity Analytics only - one smol nit 🙏

[macroscopeapp]

🟢 Low graph/fetch_events_graph.ts:378

The REPLACE(..., "[,]+", ",") pattern on line 380 corrupts field values that contain consecutive commas. For example, if a user.name value is "Test,, User", the resulting JSON "user.name":"Test,, User" becomes "user.name":"Test, User" after the replace operation, losing data. The old code used leading comma prefixes per property and did not have this data-loss risk. Consider removing the [+,]+ pattern or using a different approach that only cleans up the structural commas between properties, not commas inside quoted string values.

     REPLACE(
       REPLACE(CONCAT("\\"sourceFields\\":", ${JSON_OBJECT_START}, ${properties}, ${JSON_OBJECT_END}), "[,]+", ","),
     "\\\\{,", ${JSON_OBJECT_START}),
   ",}", ${JSON_OBJECT_END})`;

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file x-pack/solutions/security/plugins/cloud_security_posture/server/routes/graph/fetch_events_graph.ts around lines 378-382:

The `REPLACE(..., "[,]+", ",")` pattern on line 380 corrupts field values that contain consecutive commas. For example, if a `user.name` value is `"Test,, User"`, the resulting JSON `"user.name":"Test,, User"` becomes `"user.name":"Test, User"` after the replace operation, losing data. The old code used leading comma prefixes per property and did not have this data-loss risk. Consider removing the `[+,]+` pattern or using a different approach that only cleans up the structural commas between properties, not commas inside quoted string values.

Evidence trail:
1. x-pack/solutions/security/plugins/cloud_security_posture/server/routes/graph/fetch_events_graph.ts lines 378-382 (REVIEWED_COMMIT) - shows the REPLACE with `"[,]+", ","` pattern
2. x-pack/solutions/security/plugins/cloud_security_posture/server/routes/graph/utils/esql_utils.ts lines 77-80 (REVIEWED_COMMIT) - `concatJsonObjectPropertyEsqlExprSafe` function showing values are inserted directly via CONCAT without comma escaping
3. git_diff between MERGE_BASE and REVIEWED_COMMIT showing the change from `REPLACE(..., "\\{,", "{")` (only fixing `{,` pattern) to the new three-REPLACE approach including `"[,]+"`
4. Elasticsearch ES|QL REPLACE documentation: https://www.elastic.co/docs/reference/query-languages/esql/functions-operators/string-functions/replace - confirms REPLACE operates on entire string with regex matching

[kfirpeled]

currently not an issue, we can ignore for now

[elasticmachine]

⏳ Build in-progress

• Buildkite Build
• Commit: 2d219bc
• Storybooks Preview
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-260174-2d219bc2a921

Failed CI Steps

• FTR Configs #161

Test Failures

• [job] [logs] FTR Configs #161 / Entity Analytics - Risk Score Maintainer @ess @serverless @serverlessQA Risk Score Maintainer Entity Calculation with test log data @skipInServerless with asset criticality modifiers calculates risk scores with criticality modifiers

History

• 💚 Build #422563 succeeded 3f0b459
• 💔 Build #422541 failed 2cc83a9
• 💛 Build #422246 was flaky fea3faa
• 💛 Build #422234 was flaky be6447e
• 💔 Build #422221 failed a32c76e
• 💔 Build #421987 failed c5cc04a