"Shift everywhere" is just the latest term for "buy more of our stuff." Heard "shift left" for years. Now they want scanning in runtime, build, IDE, everywhere. It's a licensing and data volume play.
My concerns:
* Agent fatigue - now need their agent in ten places instead of two.
* Alert overload - more sources means more noise, not better signal.
* Compliance gap - does their runtime sensor have the same SOC2 audit scope as their static scan? Doubt it.
* Actual efficacy - show me the pen test report comparing "shift everywhere" to a focused, well-tuned pipeline. Bet the reduction in actual risk is marginal.
It's buzzword compliance, not security compliance.
Trust but verify
Yeah, that licensing angle is something I hadn't considered. So it's less about a new security model and more about expanding the places they can charge you? That tracks.
The "alert overload" point really hits home for me. We're a small team, and we already get buried in alerts from just a couple tools. Adding more sources sounds like a fast track to ignoring everything.
Do you think any vendors are doing this "shift everywhere" approach well, or is it pretty much all just a upsell tactic?
"Fast track to ignoring everything" is exactly right. It's the same problem I've seen with sales tools that spam you with 'intelligence' notifications. Adding ten more sources doesn't give you ten times the insight, it just teaches your team to mute the channel.
On the licensing, oh it's absolutely an upsell. Think about it - they've sold you the 'shift left' platform. Market's saturated. Their growth team needs a new acronym to sell into the same accounts. "Everywhere" is that acronym. It turns a single pipeline tool into a suite you need to bolt onto every stage, and the runtime component is always a separate SKU with its own fun surprises at renewal.
As for anyone doing it well? I'm skeptical. The fundamental issue is that each of these 'places' has a different context. An agent in your IDE needs to be lightweight and fast, a runtime sensor needs to be bulletproof. No vendor is great at both, they just reskin the same engine and call it a feature. You're better off picking the best-in-class tool for the one or two stages you actually need to secure, not buying a mediocre suite for everything.
Your point on alert overload for small teams is critical. From a RevOps lens, we see the parallel when sales teams get flooded with "activity intelligence" from ten different point solutions. The signal-to-noise ratio collapses, and adoption plummets. The vendor's growth metric goes up (seat licenses, data points ingested), but your security posture doesn't improve proportionally.
On whether any vendor does it well, the economic incentives are misaligned. Their revenue is tied to expanding footprint and data volume, not to reducing your total actionable alerts. A well-integrated approach would prioritize deduplication and context correlation across stages, but that's a cost center for them, not a feature they can easily charge a premium for.
The few cases where it might work are environments with the maturity to define severe, pipeline-breaking policies that are consistent from IDE to runtime. Otherwise, you're just buying more dashboard tiles.
Nail on the head with the economic incentives. Their renewal quota isn't based on how many real problems you fixed. It's about data volume and endpoint count.
That "pipeline-breaking policy" idea is the only way this isn't just expensive wallpaper. But I've yet to see a org with the stomach to actually break a prod deploy because the IDE plugin and the runtime agent have a *consistent* Sev-1. They'll just tweak the thresholds until the noise stops and call it a day.
Keep it simple, stupid