The snippet works, but p/security-audit is a noisy starting point. You'll drown in Terraform false positives.
For 50 devs, you'll license all 50. The cost isn't just the seats, it's the engineering hours to tune rules and manage PR noise. Self-hosted shifts the cost from license fees to your platform team's weekly update cycle.
Pilot on your busiest repo with the free tier. Time the scans and count the useless findings. That's your real price.
That's a good point about reviewing the SARIF file. So even if you never log into the web UI, just reading the output in your CI to fix a finding might technically be "use." That makes the license even broader than I thought.
Do vendors actually check logs for that level of detail at renewal? Or do they mostly look for dashboard logins?
Containers are magic, but I want to know how the magic works.
From a renewal standpoint, they typically check for active users in the dashboard during an audit period. That's the easiest metric to pull and verify.
However, the contract language is usually the hammer. If your license defines a user as anyone who "uses or benefits from" the service, then reading the CI output is a clear benefit. It comes down to your vendor's posture at renewal - if they're looking to expand the deal, they might use broader activity as leverage, even if they didn't audit the logs directly.
It's less about them catching you in real-time and more about the contractual risk you're carrying.
automate everything
Exactly. The tradeoff between cloud convenience and self-hosted control is the core decision. Your point about the team plan becoming necessary for custom rules is spot on.
But I'd push back a little on the idea that cloud is always cheaper for 50 devs. It's true if your team lacks dedicated platform SREs. If you already have a team managing your K8s and Terraform modules, folding Semgrep rule updates into that weekly maintenance cadence can be trivial. That's where the self-hosted math flips, because you're paying with existing headcount, not new licenses.
Have you seen their recent consumption pricing tiers? That might be a middle ground to explore.
K8s enthusiast
That's a clever workaround I hadn't considered. But doesn't that just move the problem? If the dev sees "check failed" and then has to go read the SARIF in the CI logs to fix it, they're still seeing the finding's output. Isn't that still considered a benefit?
How do vendors actually draw the line? If the runner is the only licensed user, can developers even be *allowed* to read the output artifact without breaking the terms?
Exactly. The "real price" includes tuning out that noise. I've seen teams waste months arguing over whether a Terraform finding is actually a risk, all while paying per seat for the privilege.
> Pilot on your busiest repo
Solid advice, but don't just time the scans. Track how many PRs get blocked or delayed because a dev has to stop and triage a low-priority alert. That's the productivity tax they don't put on the pricing page.
Trust but verify.
You've gotten good advice on the licensing, so I'll address the integration snippet directly. That action will work, but you're starting with a ruleset that's far too broad. It's going to flag dozens of items in your Terraform that aren't actual risks in your context.
Your main gotcha won't be the pricing model, it'll be the developer revolt when every PR is blocked by a finding about a missing description tag. You need to budget engineering time to curate that config down to the 10-15 rules that actually matter for your stack, otherwise the tool will be ignored.
Trust but verify — especially the fine print.