Security budgets are now spent across a vocabulary that changes every few years: SAST, DAST, SCA, IaC, CSPM, CWPP, CIEM, CNAPP, ASPM, DSPM, AI-SPM. Vendors use the acronyms to position, analysts use them to group, and the result for a buyer is a market map that looks like eleven separate problems. It is really three jobs, and the categories are merging around them.
In short
- There are three jobs. Find what is wrong in what you build, find what is wrong in where it runs, and decide what to fix first.
- Categories are converging. Code-side tools are moving to the cloud, cloud platforms are moving into code, and both are adding a prioritisation layer on top.
- ASPM is the decision layer. It does not replace scanners; it correlates them, adds context and owns the queue.
- Buy for the job, not the acronym. Ask any vendor which of the three jobs they do well, and which they leave to someone else.
The acronyms in one table
Most of these terms were named or popularised by industry analysts, particularly Gartner, to describe where buying behaviour was clustering. The definitions below are deliberately plain.
| Category | What it does | Where it looks |
|---|---|---|
| SAST — static application security testing | Reads source code for insecure patterns such as injection and unsafe deserialisation | Code |
| SCA — software composition analysis | Lists open-source dependencies and their known vulnerabilities and licences | Code, packages |
| Secrets detection | Finds credentials committed to repositories, ideally across history | Code, git history |
| IaC scanning | Checks Terraform, CloudFormation and Kubernetes manifests before deployment | Code |
| DAST — dynamic testing | Attacks a running application from the outside | Running apps |
| API security | Inventories APIs, finds undocumented ones, tests and monitors them | Running apps, traffic |
| CSPM — cloud security posture management | Checks cloud configuration against benchmarks | Cloud control plane |
| CIEM — cloud infrastructure entitlement management | Analyses what identities can actually do, and what they use | Cloud identity |
| CWPP — cloud workload protection | Protects running workloads: vulnerabilities, runtime detection | Hosts, containers |
| CNAPP — cloud-native application protection platform | A bundle of CSPM, CIEM, CWPP and more, sold as one platform | Cloud, increasingly code |
| ASPM — application security posture management | Correlates findings across tools, adds context, prioritises and tracks remediation | Everything above |
| AI-SPM and AI security | Inventories models and agents and checks how they are used | Code, runtime |
Three jobs, not eleven products
prioritise, assign owner"] end J1 --> J3 J2 --> J3 style J3 fill:#ccfbf1,stroke:#0d9488
Detection categories feed one decision layer.
Seen this way, most buying confusion comes from vendors that are strong in one job describing themselves in the vocabulary of another. A cloud platform that added a code scanner is still, mostly, a job-2 product. A code security vendor that added cloud posture checks is still, mostly, a job-1 product. Both now claim job 3.
Where the market is moving
Convergence from both ends
Cloud security platforms have pushed “left” into code and pipelines, so that a misconfiguration found in production can be traced to the Terraform that created it. Application security vendors have pushed “right” into runtime and cloud, so that a vulnerable library can be ranked by whether its service is exposed. The common phrase is code to cloud.
Consolidation through acquisition
The last few years have seen large acquisitions on both sides of that line, culminating in Google’s announced agreement in March 2025 to acquire Wiz for about USD 32 billion. Large platform vendors have bought specialist ASPM, API security and supply-chain companies to fill gaps. For buyers, that means fewer independent vendors and more suites, with the integration quality varying a lot between the parts that were built and the parts that were bought.
The decision layer becomes the product
As detection commoditises — many of the best engines are open source — the value moves to deciding what matters: exploitation data, reachability, business context and ownership. That is why nearly every vendor in every category now describes a risk-prioritisation feature.
Positions are illustrative, to show the direction of travel rather than rank vendors.
Who does what today
Naming the field honestly is more useful than pretending it is empty. Each of these vendors is a reasonable choice for somebody.
Code security and SCA
Strong engines and developer workflows. InsightFortify uses open-source engines here (Opengrep, Trivy, Gitleaks, Syft, Checkov) and accepts SARIF and other outputs from commercial ones.
Cloud and CNAPP
Broad cloud coverage with mature graph analysis. InsightFortify covers posture through Prowler, AWS identity analysis, attack paths and Falco runtime events in the same queue as code.
ASPM and risk-based vulnerability management
The closest comparison. InsightFortify’s difference is that it ships its own scanning, scores with factors you can read, and runs inside your cloud.
Questions that cut through positioning
| Question | What a good answer sounds like |
|---|---|
| Which of the three jobs do you do natively, and which through partners? | A specific list, not “all of them” |
| Can I bring findings from scanners I already own? | Yes, through SARIF, CycloneDX and documented formats, with correlation |
| Show me why this finding is ranked first. | A breakdown of factors, not a proprietary score |
| Where does my source code go? | Nowhere outside my environment, or an exact account of what is sent |
| What happens to my data if we leave? | Export through an API in documented formats |
| How do you count a finding? | Unique and deduplicated, with raw counts shown separately |
Suite or best of breed?
The central buying decision in this market is no longer which scanner. It is whether to buy one platform that does most jobs adequately, or to keep the specialist tools each team prefers and add a decision layer above them. Both are defensible. They fail in different ways.
Fewer contracts, one console and one data model. Risk: the parts that were acquired rather than built integrate poorly, and switching costs rise every year. Teams that preferred a specialist tool may keep it anyway, recreating the sprawl.
Each team keeps the engine it trusts; the layer correlates, adds context and owns the queue. Risk: more contracts, and the layer is only as good as its integrations and its handling of each input format.
A practical test: list the findings your teams acted on last quarter and ask which tool produced the information that made someone act. If one platform already accounts for most of them, consolidation is cheap. If the answer is spread across several specialist tools, a decision layer is cheaper than a migration.
Running an evaluation that means something
Three to five repositories of different languages, one container registry, one cloud account with real workloads.
Raw findings from current tools, and how many were acted on last quarter.
Same scope, same week. Insist on raw, unique and actionable counts.
For each candidate’s top 20, ask the owning team: would you fix this now? The share of yes answers is the most useful metric you will get.
For three findings, can the tool show why it ranked them where it did?
Export everything through the API. Confirm you could leave.
The developer-judged top 20 is worth emphasising. Detection counts reward the noisiest tool. Developer agreement rewards the one that understands your environment, which is the job you are buying a decision layer to do.
What it means for the budget
Most security budgets were built category by category, each line justified when it was added. Re-reading them against the three jobs often shows heavy overlap in detection — several tools finding the same vulnerable packages, two products checking cloud configuration — and little or nothing allocated to the decision layer, which is left to analysts with spreadsheets.
The re-balancing that tends to pay back is modest: retire one overlapping detection tool at its next renewal and redirect part of the spend to correlation, context and remediation. That funds the job that reduces risk without asking for net-new budget, which is often the difference between a proposal that is approved and one that is deferred.
Where InsightFortify fits
InsightFortify is built for job 3 with enough of jobs 1 and 2 to stand on its own. It runs open-source scanners for code, dependencies, secrets, IaC, web applications, APIs, AI and AWS, Azure and Google Cloud posture, accepts results from others, and puts every finding through the same correlation and scoring. Identity analysis and attack paths currently cover AWS. It is deployed in your own cloud account.
For the CISO
Map your current tools to the three jobs before the next renewal. Overlap in job 1 and a gap in job 3 is the most common pattern.
Consolidation can save licence cost, but only if the suite does each job well enough.
For the AppSec lead
Decide which engines you trust and keep them. Evaluate the decision layer on your own data, not a demo.
Insist on open input formats so the layer is not tied to one vendor’s scanners.
For the board
The category names will keep changing. The questions do not: what is wrong, where, and what is being fixed first.
Expect fewer, larger vendors; ask how dependent the organisation is on any one of them.
Eleven acronyms describe three jobs: find what is wrong in what you build, find what is wrong where it runs, and decide what to fix first.
Most organisations are well equipped for the first two. The third is where risk is actually reduced.