Software composition analysis is usually priced by developer count, repository or project count, scan volume, or a platform bundle. None is better in general. What matters is whether the metric grows with something you control, and whether you can predict it a year from now. Ask for the metric in writing and model it.
The common metrics
Per developer. You pay for each person who commits code or uses the tool. It is simple to forecast when headcount is stable. It can feel unfair when many contributors touch few repositories, or when contractors come and go, so ask how a contributor is counted and over what window.
Per repository or project. You pay for each codebase scanned. This suits small teams with few large repositories. It punishes microservice estates, where hundreds of small repositories each count. It also raises the question of what counts as a project in a monorepo.
Per scan or usage. You pay for work done. It can look cheap early and then climb as you add continuous scanning, pull request checks and container rescans. Ask whether all triggers count the same.
Per asset or per workload. Common when SCA is part of a wider platform. The unit may be a container, a host or an application. Check what happens when images are rebuilt often.
Platform bundle. SCA comes as one module of a suite. The sticker cost of the module may be low, but you may be paying for pieces you do not use. Compare it against what you would otherwise buy.
How to compare without comparing prices
Do not compare list numbers across vendors with different metrics. Instead, take your own numbers: active developers, repositories, services, pipelines per day, images built per week. Run each metric against them and see what each vendor's bill would respond to as you grow.
Then run two scenarios. In the first, you double your repositories because the team splits services. In the second, you add twenty contractors for six months. A pricing model that behaves badly in a scenario you consider likely is a risk, whatever the starting number.
Questions that surface hidden costs
- Which features are included, and which are add-ons: reachability, fix automation, license policy, SBOM export, single sign-on, audit logs?
- Are there limits on scans, history retention or API calls?
- What happens when we exceed the metric: a stop, an overage, or a conversation at renewal?
- Is there a minimum term, and how do renewals change the metric?
- What does leaving cost in terms of data export?
When a free option is enough
If you have one or two repositories, a single package ecosystem and a developer who will check results weekly, free tools and the alerts your code host provides may be enough. Pay when the work of reconciling many sources, enforcing policy and producing reports for others costs more than the tool.
Where Safeguard fits: Safeguard offers SBOM and dependency scanning, and the free scan at gold.safeguard.sh/scan needs no commitment. For commercial terms, ask the team directly.
Quick check
Which pricing metric is cheapest?
It depends on your shape. Many small repositories favor per developer. A few large ones with many contributors favor per repository.
Last reviewed: 19 October 2026.
