SDLC, DevOps & Developer Experience · Chapter 12 of 15
The security tooling landscape, and what the evidence supports
How each product is priced, what 'open source' is doing in the marketing, and the honest state of false-positive claims.
Application security tooling is a crowded market with unusually unreliable marketing. This chapter is what each category actually does, how the pricing models shape behaviour, and what can and cannot be said about accuracy.
The pricing models, because they change behaviour
| Model | Used by | What it does to you |
|---|---|---|
| Per contributing developer | Most scanners | Watch the definition — one product counts anyone who committed to a monitored repository in the last 90 days, so contractors, interns and occasional architects all count |
| Per contributor, per product | Some | You choose which products to enable per person, which is more honest and more administration |
| By lines of code | One major static-analysis vendor | The only one priced by codebase size rather than headcount. Great for a small team on a large monolith's headcount and terrible for its bill — and it creates a perverse incentive to exclude directories from analysis to stay in a price band |
| Per image or catalogue | Hardened-image vendors | You are buying the absence of findings rather than their detection |
| Not published | The enterprise platforms | Which is itself a signal about deal size |
What 'open source' is doing in the marketing here
This category uses the phrase more loosely than almost any other, and the distinctions are worth being precise about because they determine what you actually get for free.
Engine open, analysis closed. One popular static-analysis tool's engine is open source — and its cross-file analysis and its curated rule set are proprietary and paid. ‘It is open source’ is true of the engine and materially misleading about the detection quality you get without paying.
Genuinely unrestricted. One widely-used container and filesystem scanner is Apache-licensed with no usage limits and no paywall on core scanning, which is why it is embedded in half the pipelines you will meet.
Copyleft that matters. One popular secret scanner is licensed under the network copyleft licence — entirely fine to use internally, and a real consideration if you embed it in a service you offer to others. People rarely check.
Read the licence and the limits, not the badge. That sentence applies to every row of this chapter.
What each category actually catches
- Dependency scanning is the highest-value and lowest-effort control, because most of your code is not yours. Its weakness is reachability — it will report a vulnerability in a function your application never calls, and the good products now try to distinguish.
- Static analysis finds patterns in your own code. Its historic weakness is context: it can see a dangerous pattern and not whether the input reaches it from an untrusted source.
- Secret scanning has one product feature worth knowing about: verification. A scanner that calls the provider's API to confirm a detected credential is actually live collapses the false-positive problem that plagues entropy-based detection. And one commercial product monitors the public code-hosting feed for your organisation's secrets — catching leaks in other people's repositories, which nothing inside your own pipeline can do.
- Container scanning must run at build and on a schedule, because a vulnerability disclosed after you built is invisible to a build-time-only scan.
- Hardened base images are a different product shape entirely: minimal, continuously rebuilt images with near-zero vulnerability counts. You are buying the absence of findings rather than their detection, which removes triage work instead of reporting it. Two things to know: the entry price is substantial, and free tiers are typically restricted to a moving
latesttag with no remediation commitment — which is disqualifying for production, because reproducible builds need pinned digests.
False positives: what can honestly be said
There is no current, independent, methodologically sound public benchmark of commercial static-analysis tools. Be suspicious of any table that claims otherwise.
The widely-quoted benchmark is a decade old, synthetic, single-language and public — which means vendors optimise against it. A high score on it is evidence of tuning, not of field accuracy.
The ‘untuned scanners produce 60–90% false positives’ figure has no traceable primary source. It matches practitioner experience and should be presented as folklore rather than as data.
What the 2026 literature does establish is that using a language model as a post-filter over scanner alerts works well — peer-reviewed work reports false-positive rates falling from over 90% on a synthetic benchmark to single digits with good configurations, and high precision on real projects. Every major vendor now ships AI triage, and the next generation of marketing claims will be about triage precision rather than detection recall.
And the metric that actually matters operationally is not the false-positive rate at all. It is the developer response rate. A scanner with a 30% false-positive rate that developers ignore is worse than one with 60% that gates a merge and gets fixed. No vendor publishes this, and it is the number you should measure yourself.
Consolidation, and one question it raises
The security-tooling market consolidated sharply. The largest single event was a cloud provider completing a very large acquisition of a cloud-security platform in early 2026 — and it raises a genuinely interesting strategic question rather than merely a commercial one.
That platform's proposition was cloud-agnostic security posture management: the tool that treated all three major clouds as equals. Its owner is now one of the three. The acquirer has committed to continued multi-cloud support, and whether enterprises heavily invested in the other two accept a competitor-owned security control plane over their infrastructure is the live question of the year. It is a good thing to have an opinion about in an interview, and the opinion should be about incentives rather than about technology.
Check yourself
What should you check in a per-developer security licence?
The definition of a developer. One vendor counts anyone who committed to a monitored repository in the last ninety days, which sweeps in contractors and occasional contributors.What does 'open source' mean for the popular static-analysis tools?
Frequently: the engine is open and the cross-file analysis and curated rules are proprietary. The free experience is materially weaker than the marketing implies.What can honestly be said about false-positive rates?
Very little from public data. The standard benchmark is old, synthetic and public, so vendors tune against it, and the widely-quoted percentages have no traceable source.What should you measure instead?
Developer response rate. A scanner developers ignore is worse than a noisier one that gates a merge and gets acted on — and no vendor publishes it.The products, and what each is actually for
Naming the categories is not much help until you can put products in them, so here they are. The first thing to fix is a category error: people compare these tools as though they all compete, and most of them do not — they answer different questions at different moments.
Read the middle panel again, because it is the whole idea. A SAST tool — static application security testing — reads your source code without running it, so it can spot a database query glued together from strings. It cannot tell you that a page is served without a certificate, because at that moment no page exists. A DAST tool — dynamic application security testing — can try the real thing, but has no idea which line of code produced what it found. Neither is better. They are looking at different objects.
What each one is genuinely for
SonarQube is the one most teams meet first, usually already installed. Its origin is code quality — complexity, duplication, maintainability, test coverage — and security rules were layered on later. That history shows: it is excellent at telling you a codebase is becoming unmaintainable, and less deep than a security-first tool at tracing untrusted input through several files. Use it for the health of the code; do not assume it is your security scanner.
Veracode is a platform covering static, dynamic and dependency scanning together, and its shape is enterprise and policy-driven: you define a written standard, and builds pass or fail against it with an audit trail. That is its real use case — not finding a bug a developer could have found, but being able to show a regulator or a customer that every release was measured against a policy. It is also, incidentally, the publisher of the research this site cites on the security of AI-generated code.
Black Duck is a software composition analysis tool, and understanding why it exists means understanding a problem most engineers have never had explained to them.
Open-source licences are a legal problem, not a security one
Every library you install arrives with a licence. Most are permissive and nobody thinks about it. Some are copyleft — the GPL family being the well-known case — and those can require that if you distribute software containing them, you make your own source available too.
That is a commercial exposure, not a vulnerability. No scanner looking for security flaws will ever flag it, because nothing is broken. The code works perfectly. The problem is the contract you did not read.
This is why an acquisition triggers a dependency scan. When a company buys another, its lawyers want to know what is inside the product they are paying for — and “a copyleft library deep in your commercial product” is the sort of finding that changes a price. Black Duck's two-decade heritage is exactly this, and its vulnerability scanning grew alongside it.
So if someone asks why you would buy Black Duck when you already have a vulnerability scanner, that is the answer.
Coverity is deep static analysis with a C and C++ heritage, used where correctness is safety-critical — automotive, medical, embedded. It is slow and thorough rather than fast and conversational. Since October 2024 it belongs to the same company as Black Duck: Synopsys sold its Software Integrity Group for $2.1 billion and it was renamed Black Duck Software. Anyone still saying “Synopsys” for application security is two years behind.
Snyk competes with Black Duck on dependencies and with the others on static analysis, and its actual product is the workflow: it aims to appear in your editor and on your pull request rather than in a console a security team looks at. Checkmarx is the incumbent in heavily regulated organisations — the most configurable and the most work to configure. Semgrep's distinguishing feature is that its rules are readable and you can write your own in an afternoon, which matters more than it sounds: a rule encoding your team's mistake is worth more than a hundred generic ones. Fortify, now under OpenText, is the other long-established enterprise scanner.
How to choose, in one paragraph
Ask what you are actually buying. If you need an auditable pass-or-fail record against a written policy, that is Veracode or Checkmarx territory and the console is the product. If you need developers to fix things without being chased, buy for the workflow — Snyk or Semgrep — because a finding nobody sees is not a finding. If your exposure is what is inside your dependencies, including legally, that is Black Duck. And if your real problem is that the codebase is decaying, none of them is the answer and SonarQube is.
And a warning that applies to all of them. Every tool here will produce more findings than you can act on, and the ones you cannot act on train developers to ignore the ones you can. There is a fuller treatment of that — false-positive rates, why reachability analysis matters, and the honest evidence about whether any of this reduces incidents — in the security tooling book.
Check yourself