Just got my first Checkmarx bill and, of course, I'm staring at the line items trying to map them to actual human concepts. The two biggest cost drivers seem to be tied to "projects" and "teams." The UI makes them look interchangeable, but they're clearly not, because my wallet feels the difference.
Let me break down what I've painfully reverse-engineered:
* **A Team is a cost center.** It's a container for users and, crucially, a billing boundary. You assign licenses (like concurrent scans) to a team. Think of it as your "AWS account" or "resource group" for Checkmarx—it's how you control access and, more importantly, track spend. Multiple teams usually means multiple invoices or cost allocations.
* **A Project is a scan target.** It's a specific application or repo you're analyzing. One team can have dozens (or hundreds) of projects. The kicker? Some licensing models charge per project (especially for historical tracking and management overhead), while others are based on the scan concurrency you allocate to the team.
The hidden fee is sprawl. If your devs create a new "project" for every feature branch because the default settings encourage it, you're bloating your instance with projects. That can lead to soft costs (admin overhead, performance lag) and sometimes hard costs if you're on a per-project pricing tier.
So, in practice: Create a **Team** for "Platform-Shared-Services" and give it 2 scan engines. Then create **Projects** under it for "Auth-Service," "Payment-API," and "Frontend-Library." Don't let the UI trick you into making a new "team" for every dev squad unless you want to manually reconcile a dozen license allocations.
Cloud costs are not destiny.
> "The hidden fee is sprawl"
Oh, absolutely. But let's play devil's advocate for a second. Is the sprawl really the tool's fault, or is it your org's inability to set sane defaults? Checkmarx gives you the rope. You're the one letting the devs tie themselves into a pretzel by creating a project for every whim.
I've seen teams that religiously enforce naming conventions and project lifecycles and they barely touch the per-project licensing cap. Meanwhile, the "agile" shop next door has 500 projects for 12 repos and wonders why their bill looks like a ransom note. The real hidden fee is not having a governance process that says "no, Bob, you don't get a fresh project for your pet feature branch; use a tag or a folder."
That said, I'll grant you the UI is a hot mess. Calling them "teams" and "projects" like they're interchangeable is a textbook UX sin. But then again, Checkmarx isn't selling UX, they're selling the ability to say "we scan everything" to your auditors.
But what about the edge case?
Sprawl is definitely a problem, but I think you're giving the pricing model too much credit. The real hidden fee is that they deliberately make teams and projects sound like they're the same thing so you can't easily audit your bill. I've seen orgs with 3 teams and 50 projects that still got hit with per-project overage fees because the license was "per team, not per project" but the fine print said something else.
You're right that governance matters, but Checkmarx knows most devs won't set sane defaults. That's by design. If they wanted to prevent sprawl, they'd limit project creation to team admins by default, not make it a per-user permission. They sell you rope, then charge you for the knots.
CRM is a means, not an end.
You've nailed the core distinction, and your breakdown is spot on for anyone trying to make sense of their invoice. The team-as-cost-center vs. project-as-scan-target is exactly right.
Your point about the hidden fee of sprawl is the critical follow-up. That's often where the governance conversation needs to start, because those licenses you allocate to the team get consumed by all those projects. It's easy to think you're covered until you see the overages.
A practical step is to lock down project creation permissions immediately. It forces a bit of thought before a new scan target gets created, which can curb a lot of that automatic branch-based sprawl.
Read the guidelines before posting
Locking down project creation is table stakes, but it's not the whole story. You also need to audit the project naming and configuration tied to your CI jobs. I've seen teams implement strict permissions, only to find their existing Jenkins pipeline was still configured with the "Create project if it doesn't exist" flag enabled, spawning a new project for every failed merge. The sprawl just became automated.
The real governance step is to treat project definitions like infrastructure-as-code. Enforce that all new projects are created via the API or a Terraform provider with a specific naming prefix tied to a service catalog. Anything else gets auto-archived after 30 days. This moves the "thought" from a manual gate to a pull request review.