Just got our renewal quote from Snyk and the proposed license count has effectively doubled. Their new definition of a "user" now seems to include anyone who *generates* a report, not just those who actively use the platform for scanning or fixing.
This creates a significant observability gap for us. We can't correlate this new cost driver to any tangible increase in value or security posture. Our automated CI/CD pipelines, service accounts, and even occasional one-off script runs are now being counted as billable users, which feels like a shift from measuring active contributors to measuring system activity.
Has anyone else experienced this? More importantly, how are you tracking and attributing this new "user" activity internally? I'm looking for data-backed approaches to understand the real footprint before we engage in negotiations. Without clear metrics, it's impossible to have a productive conversation about value.
- GG
- GG
Ugh, yes, and it hits CI/CD particularly hard. That shift from "active contributor" to "any report generator" is brutal. We ran into this with our scheduled Jenkins jobs that run Snyk CLI for nightly scans. Each job's service account started getting flagged.
My workaround, while we fought it, was to funnel all automated scanning through a single, dedicated service identity. It's a hack, but it consolidated dozens of pipeline "users" into one billable seat. The trick is making sure your aggregated reports still have enough context (like a `project` or `branch` label in the command) to be useful.
Have you looked at your Snyk API audit logs? They're buried, but you can sometimes map the user IDs back to your own systems to prove which are truly automated versus human. It gave us the ammo to get a few seats removed.
Vim > Emacs, fight me.
Yep, saw the same thing. The new definition is pure revenue engineering.
Good luck with the metrics approach. We tried that, but the numbers they give you are a black box. You'll waste time mapping their "user" IDs when the real question is why you're paying per seat for automated systems at all.
This is exactly why we moved critical scanning into the pipeline itself with open source tools. Snyk became a reporting layer, not the scanner. Their pricing model forces that kind of contortion.
Keep it simple
I agree with your assessment of the metrics black box. Our experience aligns; the API audit logs provide data, but not the *semantics*. You can see a user ID triggered a scan, but you cannot differentiate a developer reviewing a pull request from a Kubernetes cron job, as both are simply "report generators" in their model.
Your architectural shift is a logical endpoint. It mirrors a framework I've seen for evaluating security tools that charge per seat: when the unit of value shifts from human productivity to system activity, you must decouple the execution engine from the management interface. This often means open-source scanners in CI/CD, with the commercial tool relegated to aggregation and policy management, if used at all.
The contortion you mention creates a secondary cost, however: increased pipeline complexity and maintenance overhead. The total cost of ownership calculation needs to include the engineering hours to build and maintain that open-source scanning infrastructure versus the inflated license fee. For some, the fee is still cheaper.
Start with the question.
Yeah, you nailed the core issue: "observability gap." You can't manage what you can't measure, and they're charging you for the unmanageable.
My team hit this exact wall. We built a simple attribution script that pulls from Snyk's activity API *and* our internal CI/CD event logs. The goal was to tag each scan event with a type: "human_triggered," "pipeline_scheduled," or "service_account_one_off." It wasn't perfect, but plotting the daily counts showed our "billable users" were 80% pipeline noise. That chart became our first negotiation slide.
The brutal truth is this pricing shift often forces a toolchain re-evaluation. Your "real footprint" analysis might show it's cheaper to run the scanner elsewhere and keep Snyk only for your security team's dashboards.
test the migration twice
That attribution script is a clever hack to get some visibility. We tried something similar, but ran into the classic "garbage in, problem to sales" issue.
The API data is structurally biased. A pipeline's service account that scans 50 repos in parallel shows up as one "user" in their logs, but our legacy system's linear scans from 50 different job IDs? That's 50 billable users. The noise isn't just volume, it's architecture-dependent. Your 80% pipeline noise might be our 95% if you've got a sprawling, older setup.
It makes that negotiation slide a moving target. 😒
My sandbox is bigger than yours.
Exactly. This is why any internal metric built on their opaque data is fundamentally flawed for comparison. You're trying to create a stable benchmark from a variable you don't control and can't audit. The architecture-dependent bias you mention means you can't even benchmark your own improvements reliably; a migration to a more efficient pipeline could look worse in their billing data because it distributes scans across more discrete job IDs.
The core failure is a classic measurement problem: they've defined the unit of consumption ("user") in a way that isn't isomorphic to any unit of value you receive. You can't normalize the data because the mapping from your activity to their metric is lossy and non-deterministic.
So your negotiation slide isn't just a moving target, it's measuring the wrong target. You need data entirely external to their system to even have the conversation.