[CSV Feed] Support relationship-based neighbor resolution in CSV Feed columns

[SamuelHassine]

Description

Currently, CSV Feeds (live URL endpoints serving data at runtime) only support columns based on the direct attributes of the targeted entity type. For example, a CSV Feed based on Indicators can include columns like indicator value, indicator type, confidence, created, updated, etc.

The feature request is to support resolving first-degree neighbors (via relationships) and including their attributes as additional columns in the CSV Feed, resolved at runtime when the feed URL is consumed.

Use Case

When consuming an Indicator-based CSV Feed, downstream systems (SIEM, SOAR, firewalls) expect a flat, enriched CSV with contextual attribution alongside raw indicators — without additional lookups. For example:

Indicator Value	STIX ID	Malware Name	Campaign Name	Intrusion Set Name	Indicator Type	Confidence	Created	Updated
1.2.3.4	indicator--xxx	EvilLoader	Operation X	APT28	IPv4-Addr	High	12/02/2026	12/02/2026

Here, Malware Name, Campaign Name, and Intrusion Set Name are not attributes of the Indicator itself — they come from resolving first-degree neighbors through relationships (e.g., Indicator → indicates → Intrusion Set, Indicator → indicates → Malware).

Expected Behavior

In the CSV Feed configuration, users should be able to:

1. Add neighbor-based columns — select a relationship type (e.g., indicates, uses, attributed-to) and a target entity type (e.g., Intrusion Set, Malware, Campaign).
2. Pick which attribute of the resolved neighbor to display in the column (e.g., name, description, aliases).
3. The CSV Feed engine resolves these neighbors at runtime when the feed URL is requested and populates the corresponding columns dynamically.

Open Design Question

If multiple neighbors match (e.g., an Indicator indicates 2 Intrusion Sets), a strategy is needed: first match, comma-separated list, or configurable behavior.

Additional Context

This is a common pattern in threat intelligence sharing workflows where consumers pull a live CSV Feed URL and expect enriched, flat data ready for ingestion — no post-processing or additional API calls required.

[SamuelHassine]

CSV Feed Neighbor Resolution in Columns

Architecture

The current CSV Feed system supports only direct attribute columns (e.g., indicator.value, indicator.confidence). We extend FeedMapping with optional fields to support neighbor-based resolution through relationships.

flowchart LR
    subgraph currentFlow [Current Flow]
        Entity["Entity (e.g. Indicator)"] -->|"direct attribute"| CSV["CSV Column"]
    end
    subgraph newFlow [New Flow]
        Entity2["Entity (e.g. Indicator)"] -->|"relationship (indicates)"| Neighbor["Neighbor (e.g. Malware)"]
        Neighbor -->|"extract attribute (name)"| CSV2["CSV Column"]
    end

Loading

Data Model Extension

Extend FeedMapping with two optional fields. When both are set, the mapping resolves a neighbor; when absent, it works as a direct attribute (backward-compatible).

Add a multi_match_strategy field to FeedAttribute (column level) for configurable behavior when multiple neighbors match.

classDiagram
    class FeedAttribute {
        attribute: String
        mappings: FeedMapping[]
        multi_match_strategy: String
    }
    class FeedMapping {
        type: String
        attribute: String
        relationship_type: String?
        target_entity_type: String?
    }
    FeedAttribute --> FeedMapping

Loading

multi_match_strategy values: "first" (first match) or "list" (comma-separated, default).

Backend Changes

1. GraphQL Schema (opencti.graphql, lines 608-656)

• Add relationship_type: String and target_entity_type: String to FeedMapping type
• Add same to FeedMappingInput input
• Add multi_match_strategy: String to FeedAttribute type and FeedAttributeMappingInput input

2. TypeScript Types (store.d.ts, lines 471-490)

• Add relationship_type?: string and target_entity_type?: string to the mapping type
• Add multi_match_strategy?: string to the feed_attributes type

3. Domain Validation (feed.ts, lines 17-38)

• In checkFeedIntegrity, validate that when relationship_type is set, target_entity_type must also be set (and vice versa)
• Validate multi_match_strategy is either "first", "list", or undefined

4. Feed Engine (httpRollingFeed.ts)

This is the core runtime logic. After loading entities (line 119), before building CSV lines:

• Add resolveNeighborsForFeed(): identifies all unique (relationship_type, target_entity_type) pairs from feed_attributes, batch-queries relationships for ALL loaded entity IDs using fullRelationsList (from middleware-loader.ts), then batch-resolves target entities with elFindByIds (from engine.ts). Returns a Map<entityId, Map<"relType:targetType", entity[]>>.
• Searches both relationship directions (source as FROM and as TO) to cover all relationship patterns
• Modify buildCsvLines(): accept the neighbors map as a parameter. For mappings with relationship_type+target_entity_type, lookup pre-resolved neighbors and extract the attribute. Apply multi_match_strategy (join with comma or take first).

Frontend Changes

5. Feed Creation (FeedCreation.tsx)

For each entity type mapping within a column row:

• Add a toggle (e.g., a small icon button or Switch) to switch between "Direct attribute" and "Neighbor attribute" mode
• Direct mode (current): shows the existing attribute dropdown
• Neighbor mode (new): shows three dropdowns:
  • Relationship type: populated using schemaRelationsTypesMapping from the auth context (leveraging existing computeRelationsDataFromTo() from Relation.ts)
  • Target entity type: scoped based on selected relationship type
  • Target attribute: fetched via stixCyberObservablesLinesAttributesQuery for the selected target type
• Add a multi-match strategy dropdown per column (only visible when any mapping in the column uses neighbor mode): "First match" or "Comma-separated list"
• Update handleChangeAttributeMapping to store relationship_type and target_entity_type in the mapping
• Update areAttributesValid() to validate neighbor mappings
• Update the onSubmit transform to include the new fields
• Extend feedCreationAllTypesQuery to also fetch schemaSCRs: subTypes(type: "stix-core-relationship") for relationship types, or leverage the schema already loaded in the auth context

6. Feed Edition (FeedEdition.jsx)

Mirror the same changes from FeedCreation. Initialize the neighbor mode state from existing feed data (detect neighbor mappings by presence of relationship_type).

7. Relay Fragments Update

All three fragments need the new fields added:

• FeedLine_node in FeedLine.jsx (line 149)
• FeedEdition_feed in FeedEdition.jsx (line 634)
• FeedCreation fragment in FeedCreation.tsx (line 670)

Add relationship_type, target_entity_type to mappings and multi_match_strategy to feed_attributes.

Performance Strategy

• Batch all relationship queries: one fullRelationsList call per unique (rel_type, target_type) pair (not per entity)
• Batch all entity resolution: one elFindByIds call for all target IDs
• Pre-compute the lookup map before iterating CSV rows
• Existing SIZE_LIMIT (5000 entities) bounds the scope

Backward Compatibility

• All new fields are optional (nullable in GraphQL, optional in TypeScript)
• Existing feeds with only direct mappings continue to work unchanged
• multi_match_strategy defaults to "list" when absent