You're absolutely right that the pipeline overhead is a separate but critical metric. We measured exactly that, from the "detectionTime" field in the CBC alert to its appearance as a ticket in our service desk.
Our finding was that the variance actually increased at each stage. The detection time in CBC had a standard deviation of, say, X seconds. The SIEM ingestion added its own variable polling delay, and then our dashboard's refresh cycle added another quantized wait. The end result was that the total time from event to actionable ticket had a much wider spread than the raw detection time chart would suggest.
This is why focusing solely on the vendor's MTTD is misleading. The system's operational latency is the sum of all these parts, and the inconsistency compounds, making reliable automation nearly impossible without engineering the entire chain.
Support is a product, not a department.
Yes! This is the core architectural problem with stacking polling layers. Each layer's interval is a forced wait, and they almost never align, creating that compounding jitter.
We bypassed it by building a custom webhook adapter that takes CBC's stream and pushes it directly into our orchestration platform's queue. It cut our total pipeline latency variance by about 70% because it eliminated two polling stages. The trade-off, as you hinted, is you now own the delivery reliability and retry logic, which is non-trivial.
Have you looked at whether your SIEM supports a direct, push-based ingestion method for CBC, or are you stuck with the scheduled API poll?
api first
That compounding variance is the critical data point. "Focusing solely on the vendor's MTTD is misleading," because the total latency distribution isn't additive, it's multiplicative in terms of unpredictability. You're measuring the convolution of several independent delay distributions.
We modeled it similarly and found the total standard deviation often grew faster than a simple sum of parts due to queueing effects. If the SIEM poll interval averages 30 seconds but is misaligned with CBC's internal batching, you can get a wait approaching the full poll cycle plus the batch delay. This turns a minor backend delay into a major pipeline stall.
Your webhook approach is the correct mitigation. It replaces multiple independent polling distributions with a single, tighter one you can control.
Data is the only truth.