Security data pipelines are becoming the new control point for SOCs

At a glance

What this is: Security data pipelines are now the control point for SOC telemetry, with the article arguing that vendor-controlled ingestion creates lock-in, blind spots and AI limitations.

Why it matters: SOC, SIEM and detection teams need pipeline ownership because the quality, routing and portability of telemetry now shape resilience, tool choice and AI effectiveness.

Context

Security data pipelines are the transport and control layer that move logs, metrics, traces and events from sources into detection and analytics tools. The governance problem is that many organisations now let vendors decide how telemetry is ingested, parsed and routed, which weakens portability and makes future change more expensive.

That matters because telemetry decisions increasingly affect both operational resilience and identity-adjacent visibility. When pipelines favour one ecosystem, teams lose the ability to route data independently, preserve context across tools and keep AI outputs aligned with real risk rather than vendor-specific blind spots.

Key questions

Q: How should security teams prevent vendor lock-in in security data pipelines?

A: Security teams should keep routing, enrichment and forwarding under their own control so they can move telemetry between tools without re-platforming. The key is to separate collection from analytics, insist on portable formats and prove that data can be delivered to more than one destination without duplication or loss of context.

Q: Why do vendor-controlled pipelines create blind spots for SOC operations?

A: Vendor-controlled pipelines tend to prioritise the vendor's preferred sources, formats and use cases, which can suppress telemetry that does not fit neatly into the ecosystem. That creates gaps in visibility, especially when custom applications, medical devices or cloud-native services need different handling. Blind spots emerge when pipeline design decides what the SOC can actually see.

Q: What happens when a SOC pipeline cannot route telemetry independently?

A: When the pipeline cannot route independently, teams lose the ability to feed multiple tools, compare analytics outputs and adapt quickly as the stack changes. The result is duplicated data, higher cost and less flexibility for AI and new detections. Independence matters because resilience is built into the flow of evidence, not only into the tools that consume it.

Q: How do organisations know whether their telemetry pipeline is resilient enough?

A: A resilient pipeline can ingest diverse sources, enrich data in motion and deliver the same telemetry to multiple destinations without forcing a vendor-specific workflow. If changing a SIEM or analytics layer requires redesigning collection, the pipeline is too tightly coupled. The test is portability under change, not just successful ingestion on day one.

Technical breakdown

Why vendor-native ingestion creates telemetry lock-in

Vendor-native ingestion looks efficient because it bundles collection, parsing and forwarding into the same ecosystem as the SIEM or EDR. The architectural trade-off is that data then inherits proprietary routing rules, formats and retention assumptions, making downstream migration difficult. Once telemetry decisions are embedded in the vendor stack, the organisation no longer controls how evidence is distributed across tools, which turns the pipeline into a hidden dependency. This is not only a tooling issue. It is a governance issue because it affects where security evidence can go, how fast it can move and which analytics layers can consume it.

Practical implication: Treat ingestion as a controllable architecture layer and preserve the ability to change downstream tools without reworking the telemetry path.

How pipeline bias weakens detection and AI outcomes

A security pipeline does more than move data. It decides which fields are enriched, which sources are prioritised and which events survive filtering. If those decisions are shaped by a single vendor's ecosystem, the resulting dataset reflects that vendor's view of the world, not the organisation's full risk picture. AI systems are especially sensitive to this because they inherit the quality and completeness of the telemetry they consume. In practice, biased routing can hide relevant context, suppress alternative signals and make model-driven detection look more capable than it really is.

Practical implication: Audit routing and enrichment logic for source and field bias before using the pipeline as input to analytics or AI-driven detections.

Why pipeline ownership is now part of SOC resilience

The webinar material frames pipelines as infrastructure rather than plumbing, and that distinction matters. Infrastructure is something the organisation should be able to control, test and adapt as business and threat conditions change. When multiple tools each bring their own shipping layer, duplication rises, operational overhead grows and visibility becomes fragmented. A neutral pipeline can route telemetry to multiple destinations without duplication, which supports experimentation and lowers dependency on any single console. That is why resilience now depends on owning the control plane for telemetry, not just buying stronger detection tools.

Practical implication: Design telemetry flow so it can feed multiple consumers independently, including SIEM, data lake and AI systems, without vendor-imposed routing constraints.

Threat narrative

Attacker objective: The practical attacker objective in this pattern is to exploit visibility gaps created by fragmented or vendor-controlled telemetry flows.

1. Entry occurs when telemetry collection is absorbed into vendor-native pipelines that dictate how logs, metrics and events are forwarded.
2. Escalation happens when proprietary routing and formatting rules make the organisation dependent on one ecosystem for visibility and analytics.
3. Impact follows as blind spots, duplicate ingestion costs and limited AI flexibility reduce the SOC's ability to adapt or detect effectively.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pipeline control is now a security governance problem, not a plumbing issue. The article shows that the real decision point is no longer only the SIEM or analytics layer, but who owns routing, enrichment and forwarding. When those decisions sit inside a vendor ecosystem, the organisation loses portability and weakens its ability to adapt controls as threats change. Practitioners should treat telemetry control as part of security architecture governance, not procurement convenience.

Telemetry independence is becoming the new boundary for SOC resilience. A neutral pipeline lets organisations send the same evidence to multiple destinations without duplication or forced loyalty to one console. That matters because resilience now depends on being able to re-route, re-enrich and re-use data as detection strategies evolve. The control problem is no longer whether data exists, but whether the organisation can move it freely enough to defend with it.

Vendor-controlled ingestion creates a hidden trust assumption. Teams assume they can swap tools later, but proprietary pipeline design often makes that promise false. The result is not just lock-in. It is a governance gap where the organisation cannot independently verify that its telemetry is complete, portable and usable across the stack. Practitioners should see that as a constraint on security autonomy, not merely an IT inconvenience.

AI-ready security depends on clean telemetry, not just smarter models. If the pipeline filters or prioritises data to suit one vendor's use case, AI outputs will mirror that bias. That makes pipeline independence a prerequisite for trustworthy detection tuning, model experimentation and cross-tool correlation. The practitioner takeaway is clear: govern data quality at the pipeline layer before expecting analytics or AI to compensate.

From our research library:

• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Identity Security Metrics and KPIs Guide

What this signals

Telemetry independence is becoming a control objective in its own right: SOC teams that cannot route data freely will struggle to preserve context, compare detections or shift analytics platforms without disruption. That makes pipeline design part of operational resilience, not a back-end implementation detail.

Pipeline bias will shape AI outcomes as much as model choice: if enrichment and forwarding logic reflect one vendor's ecosystem, model outputs will inherit that narrow view. Practitioners should govern the pipeline as the input boundary for detection quality, because downstream AI cannot correct incomplete telemetry.

Blind spots multiply when collection, enrichment and forwarding are split across vendor stacks: teams then spend more time reconciling duplicate data and less time improving coverage. The practical signal is simple: if telemetry cannot be re-routed independently, the SOC has less control than it thinks it does.

For practitioners

• Define pipeline ownership and decision rights Assign clear authority for routing, enrichment, filtering and forwarding so telemetry decisions are not embedded inside a single vendor console.
• Map telemetry dependencies across the SOC stack Document which tools ingest which logs, metrics, traces and events, then identify where proprietary formats or routing rules block portability.
• Test multi-destination routing without duplication Validate that the same telemetry can reach a SIEM, a data lake and analytics tools without double billing or loss of context.
• Review enrichment rules for source bias Check whether the pipeline favours vendor-native sources or suppresses context from medical devices, SaaS APIs or custom applications.
• Separate ingestion convenience from control resilience Require an architecture that preserves the ability to change downstream tools without re-platforming the collection layer.

Key takeaways

• Security data pipelines now influence visibility, portability and analytics quality as much as the SIEM or detection tool that sits downstream.
• When telemetry routing is controlled by vendors, organisations risk lock-in, blind spots and weaker AI outcomes because the pipeline shapes what the SOC can actually use.
• The practical response is to treat pipeline ownership as a resilience requirement, with routing and enrichment decisions kept under practitioner control.

Key terms

• Security data pipeline: A security data pipeline is the chain that ingests, filters, enriches, normalises, and routes telemetry before it reaches storage or analytics. In practice, it determines which evidence survives into detection, investigation, and compliance workflows, so it is part of the control environment, not just infrastructure plumbing.
• Telemetry Normalization: Telemetry normalization is the process of turning data from different security tools into a consistent format that can support one policy decision. It is essential when identity, endpoint, and asset systems all feed the same control plane, because conflicting data can otherwise create gaps or overblocking.
• Vendor Lock-In: A dependency state where business processes, technical integrations, and identity controls become difficult to move away from without disruption. It is not only a commercial constraint. It also creates governance friction when credentials, APIs, and monitoring workflows are tied too tightly to one provider.
• Telemetry Enrichment: Telemetry enrichment is the process of adding context to raw security data so it is more useful for investigation and response. That can include asset, identity, geolocation, or threat intelligence context, but enrichment must be controlled so it does not distort the original evidence record.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity control to the broader security architecture their programmes depend on.