The "Veracode tax" is a perfect way to put it, and it's a concept more teams should track. That internal audit trail you're building for workarounds ends up being more valuable for actually running your program than some of the official outputs.
It really does highlight the gap between what's sold and what's used day-to-day. The product team using a clean test env is a solid hypothesis, ha. I'd bet the disconnect is between the teams building the core scan engine and the ones responsible for the pipeline plugins. The latter often don't have the same clout or resources, so the real-world friction gets deprioritized.
Makes you wonder if they'd fix it faster if they had to eat their own dog food and use those plugins under real pipeline load.
Keep it constructive.
>The pipeline integration is clunky.
This is the core engineering failure. That clunkiness is overhead that directly impacts developer cycle time. We measured the pipeline plugin latency at 45-90 seconds of pure wait, irrespective of scan time. That's a recurring tax on every merge request.
The rest of your post - dated reporting, slow support - are symptoms. They're selling a compliance artifact, not a tool optimized for an engineer's workflow.
Data over opinions
That's a really interesting point about it being neglect vs. a deliberate tier. I hadn't thought of it that way.
If the API/CLI is the primary interface for them, it does explain why the plugin feels like an afterthought. It's almost like they built the core product and then said "oh right, people will want this in their pipeline," but didn't give that team what they needed.
>you can't afford a dedicated TAM, so you get the slow queue.
This hits home. We're definitely in that mid-market bracket, and the support delay is real. We just accept it now.
Do you think a truly well-funded plugin team would actually make a difference, or is the whole approach flawed? Like, is it fundamentally harder to make a robust plugin than they let on?
You're right about the dedicated VM becoming a pet. We considered that route last quarter, but our ops team's back-of-the-envelope math killed it. They estimated the admin time for patching and network config would've consumed the time of a junior SRE for about a day a month.
That's a real, soft cost that isn't in any of their sizing guides. It makes the "predictability" argument feel like a shell game.
I'm curious, did you ever try to quantify that operational overhead, or was it more of a gradual, qualitative drain on your team's focus?
Totally agree on the onboarding for juniors being a genuine win. That eLearning content is surprisingly practical, not just fluffy theory. It really did shorten the learning curve for our new devs.
But I think you've nailed the core trade-off. You're getting that solid SAST engine and good training material, but you're paying a steep premium for what feels like an incomplete daily experience. The gap between the core scanner and the clunky pipeline integration is where the frustration lives.
I've always wondered if they'd prioritize fixing that pipeline lag if their own engineering velocity depended on it.