[Sébastien MIGUEL (Seb-MIGUEL)]

Adds a native file finding type end to end and surfaces it in the attack path, so files discovered on SMB shares (NetExec spider_plus) become first-class findings.

Completes the kill-chain: nmap → 445 → SMB → enum shares (share) → spider_plus (file on that share) — e.g. a secret.ps1 on SYSVOL holding a hard-coded password shows up as a file finding you can pivot from.

Self-contained: the interim share → file stand-in removal (formerly #6999, now closed) is already folded into this PR. Targets main.

Why complex, not primitive

The same basename means different things by location. A file is a complex finding carrying file_name + path + share (empty for local files, e.g. a future FTP/NFS --ls) + host. Its stored value is the full location (a unique dedup key, so two secret.ps1 never merge) while the front renders only the basename; the share sub-field reuses PrimitiveType.ShareName so a share-hosted file links back to its share finding.

Changes

Model / chaining — ContractOutputType.File, PrimitiveType.FileName + FilePath, ComplexType.File; registered complex with its sub-field → primitive map (file_name→FileName, path→FilePath, share→ShareName, host, asset_id).

API — FileOutputProcessor (complex, mirrors ShareOutputProcessor): validate requires file_name; toFindingValue builds \\host\share\dir\file for share files, a host-prefixed path for local files. AttackPathGraphService gains a files counter + files drawer category (mirrors shares); AttackPathKeyMatcher reconciles file_name → file; AttackPathCounters gains files.

Front — maskFindingValue shows a file as its basename (full path in the detail panel); "Captured Files" card + files filter/category; ContractOutputElementType.file; api-types (AttackPathCounters.files, "file" in the type unions); i18n across all nine locales.

Docs — updated the add-contract-output-type skill: a located file is complex (not primitive), and the JSON-metadata output path used by spider_plus.

Tests (validated locally)

• FileOutputProcessorTest (10) — validate + value formatting (UNC / local / same-name-distinct-by-share).
• ChainingTypeRegistryTest — File resolves complex, sub-fields → primitives incl. share→ShareName.
• AttackPathShareTypeApiTest — extended: share and file each count under their own name; file on graph node / collapsed counts / files counter.
• Front: maskFindingValue('file') → basename, FILTER_TO_FINDING_TYPES.files, findingCategoryNoun('file'). check-ts + eslint + vitest green.

Dependencies

• client-python: feat(contracts): add file output type (#329) client-python#322 (file output type)
• netexec injector: feat(netexec): emit file findings from spider_plus share spidering (#390) injectors#387 (spider_plus producer)

Behind the ATTACK_PATH feature flag.

[github-actions]

/review docs

📖 Docs Reviewer triggered automatically.

27 files changed — 22 functional, 0 documentation.

⚠️ No documentation files modified. Agent will check if doc updates are needed.

[Laurent Giovannoni (laugiov)]

Two things before merge:

• Rebase onto current main, it's conflicting right now.
• Drop "review fix(attack-path): keep SMB findings under the share type instead of relabelling them as file (#6647) #6999 first" from the description: fix(attack-path): keep SMB findings under the share type instead of relabelling them as file (#6647) #6999 is closed and its commit is already folded in here, so the PR is self-contained.

Heads-up: the rebase will hit the just-merged #7017 (complex-finding sub-field matcher), which still carries the interim share_name -> file that your PR moves to native share/file. That matcher is my area, I'll pair with you on the reconciliation so nothing regresses.

[Sébastien MIGUEL (Seb-MIGUEL)]

Thanks Laurent.

• Description: done — dropped the "Stacked on fix(attack-path): keep SMB findings under the share type instead of relabelling them as file (#6647) #6999 / review fix(attack-path): keep SMB findings under the share type instead of relabelling them as file (#6647) #6999 first" section; it now reads as self-contained, targeting main.
• Rebase: attempted onto current main and it confirms exactly what you flagged. The real manual conflicts are two front files that are mine — SimulationAttackPath.tsx and attack-path-flow-helpers.test.ts — I'll take those. The catch is that git auto-merges AttackPathKeyMatcher.java and AttackPathGraphService.java with no conflict marker: my commits move the reconcile map (share_name → file ⇒ share_name → share + add file_name → file), and feat(chaining): match complex-finding sub-fields for kill-chain events (#6647) #7017 rewrote that matcher on top of the interim share_name → file. So the map line silently layers onto your new sub-field logic without anything validating that share/file still resolve correctly — precisely the silent-regression risk you mentioned.

Rather than push that auto-merged resolution, I'd like to take you up on the pairing offer: I'll resolve the two front conflicts, and we settle AttackPathKeyMatcher / AttackPathGraphService together (target state of the reconcile map + confirm your sub-field matcher handles the native share/file types). How do you want to do it — you push the intended matcher state and I rebase on top, or we go through it live?

[Laurent Giovannoni (laugiov)]

Thanks Seb, you're right that the matcher is the real silent-regression risk. I dug into both backend auto-merges and they're not equal:

• AttackPathGraphService, the auto-merge is actually correct, keep it. Your presentType removal and feat(chaining): match complex-finding sub-fields for kill-chain events (#6647) #7017's applyEventDependencies/matchedFindingIds are in disjoint regions, so they merge cleanly, and once findings are native they flow straight into matchedFindingIds, which is what we want. Don't reset it to main (that'd re-add the bridge you're removing); the tests will confirm it.
• AttackPathKeyMatcher, this is the one, leave it to me. The auto-merge takes your share_name->share but keeps feat(chaining): match complex-finding sub-fields for kill-chain events (#6647) #7017's SUBFIELDS["file"]={share_name->…}, so share_name EQ stops extracting from share findings and starts spuriously matching file basenames. I'll push the reconciled matcher + tests so it's proven, not assumed:
  • map -> your target (share_name->share, file_name->file, password->credentials) OK
  • SUBFIELDS: move the share_name extractor from file to share; add file_name -> basename under file
  • update AttackPathKeyMatcherTest + the kill-chain graph test to native share/file

So: you take the two front files + keep the graph-service auto-merge; I own the matcher + its tests.

One thing to confirm: your registry maps file.share -> ShareName, so I could let share_name also match file findings. I'd scope the graph matcher to share_name -> {share} only (a file isn't a share, otherwise spurious edges); the file->ShareName link stays a runtime-chaining concern. Good with that?

[Sébastien MIGUEL (Seb-MIGUEL)]

Rebased onto current main and force-pushed — tip is now 057376d3a (was 303d30b5f). Ready for your matcher commit whenever.

What I took (front) + the graph-service auto-merge

• SimulationAttackPath.tsx — the only real conflict was the import block: main added Fullscreen* / IconButton / Pagination, my branch added Popover / alpha and re-added InsertDriveFileOutlined. Resolved to the union (checked each symbol is actually used, no dead import).
• AttackPathGraphService.java — kept the auto-merge exactly as you called it, did not reset to main.

Heads-up: the auto-merge silently corrupted one of my front tests — the same risk you flagged, but on the front side

• The hub test (collapses N findings … single causal edge) auto-merged my share fixture with main's file assertions (toHaveLength(3) + NODE_FINDING|file| source). Restored to the intended native-share assertions (toHaveLength(1), NODE_FINDING|share| source).
• Main's two new front tests — collapses more than 4 … cluster and anchors the causal edge on the resolved producer — were written against the interim share_name → file bridge (file producers consumed by share_name IS_NOT_NULL). The merged front helper reconciles share_name → share only, so I migrated both fixtures from file to share; the tests stay, they just exercise the clustering/anchoring under the native type now.

Didn't touch AttackPathKeyMatcher / AttackPathKeyMatcherTest — all yours.

On the share_name scope question — yes, agreed: scope the graph matcher to share_name → {share} only. A file isn't a share, and matching file findings on share_name would re-introduce exactly the spurious cross-type edges this PR removes. The file.share → ShareName registry link stays a runtime-chaining concern, out of the graph matcher. FWIW the front already reflects this — KEYTYPE_TO_FINDING_TYPE maps share_name → 'share' only — which is why the two front tests above had to move to native share.

One caveat: I couldn't run the front suite locally in this worktree (its node_modules carries the WSL/Linux native bindings, so a Windows vitest can't load @rolldown/binding-win32-x64-msvc) — the front resolution is static-analysis-backed and I'm leaning on CI. Backend matcher tests will be red until your commit lands, as expected.

[codecov]

Codecov Report

❌ Patch coverage is 89.83051% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 44.44%. Comparing base (57ce8b0) to head (8632d90).

Files with missing lines	Patch %	Lines
...enaev/service/attackpath/AttackPathKeyMatcher.java	57.14%	1 Missing and 2 partials ⚠️
...simulation/attack_path/attack-path-flow-helpers.ts	50.00%	1 Missing and 1 partial ⚠️
.../openaev/output_processor/FileOutputProcessor.java	96.00%	0 Missing and 1 partial ⚠️

❌ Your project check has failed because the head coverage (7.48%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7016      +/-   ##
============================================
- Coverage     44.48%   44.44%   -0.05%     
+ Complexity     9628     9626       -2     
============================================
  Files          2733     2734       +1     
  Lines         83446    83450       +4     
  Branches      12815    12827      +12     
============================================
- Hits          37125    37089      -36     
- Misses        43552    43569      +17     
- Partials       2769     2792      +23     

Flag	Coverage Δ
backend	67.73% <91.83%> (-0.03%)	⬇️
e2e	16.93% <ø> (-0.93%)	⬇️
frontend	7.48% <80.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.