Application Security Testing Converges into Platform Race as AI Reshapes Market

On June 3, 2026, Invicti Security announced the launch of Invicti AppSec Core, an all-in-one application security platform that combines static analysis, dynamic testing, and runtime protection into a single product. The press release, carried by PRNewswire, described the move as a response to "the fragmented toolchains that security teams navigate daily." Invicti was not the first vendor to combine these functions. It was, however, the latest signal that the three-decade separation between SAST, DAST, and runtime application security is ending.

The announcement did not come from nowhere. On April 9, the same company released what it called "DAST-to-SAST correlation," a feature designed to map vulnerabilities found in running applications back to the specific lines of code that produced them. That earlier release targeted a structural problem: dynamic scanners find evidence that something is exploitable, but the fix belongs in source code, and the gap between the two findings has historically been bridged by a developer squinting at two separate dashboards. Closing that gap is the functional definition of convergence.

To understand why the three categories are collapsing into one, it helps to understand what each was built to do. SAST, static application security testing, scans source code without executing it. It finds patterns: an unsanitised input, a missing authentication check, a hardcoded secret. Its limitation is the false positive. A SAST tool flagging a potential SQL injection cannot know whether the input ever reaches a database. DAST, dynamic application security testing, attacks a running application from the outside, sending malicious payloads and observing the response. It finds exploitable vulnerabilities but cannot tell a developer which line of code to fix. Runtime analysis, the third leg, sometimes called IAST for interactive application security testing, instruments an application from the inside while it runs, observing data flow through libraries, frameworks, and custom code. It sees what actually executes.

Each category was built by a different generation of vendors, sold to a different buyer, and integrated into a different stage of the software development lifecycle. SAST belonged to the build pipeline. DAST belonged to the pre-release security review or the external penetration test. Runtime belonged to production operations or, in the case of IAST, to the quality assurance phase. The organisational boundaries were as rigid as the technical ones. That arrangement held for roughly twenty years.

Two forces broke it. The first was speed. When deployment cycles shortened from quarters to weeks to hours, the sequential model, scan, then test, then monitor, became untenable. A dynamic scan that takes three days to complete is useless against a pipeline that ships code ten times a day. The second force, arriving with impact in early 2026, was the entry of large language models into application security. On February 20, Anthropic released Claude Code Security. Fourteen days later, on March 6, OpenAI launched Codex Security. As VentureBeat reported on March 10, "both scanners use LLM reasoning instead of pattern matching," a distinction that matters because reasoning-based analysis can understand code semantics, not just syntax.

The LLM-native scanners do not fit neatly into the SAST category even though they analyse source code. A traditional SAST rule might flag eval(user_input) regardless of context. A reasoning scanner can trace whether user_input is ever attacker-controllable at that point in the program's execution, reducing the false positive rate that has made SAST output a triage problem for two decades. The scanners are new and their coverage is narrower than established tools, but the signal matters: if a free tool from a foundation model provider can match the precision of a commercial SAST product on common vulnerability classes, the unit economics of the category shift.

The platform vendors saw this coming. Invicti's AppSec Core bundles SAST, DAST, and IAST under one licence and one interface. The product's architecture runs static analysis at the pull request, dynamic scanning in the staging environment, and runtime instrumentation in production, correlating findings across all three. The company's claim is that a vulnerability detected at runtime can be traced to the SAST rule that missed it and to the DAST payload that confirmed it, all within the same platform. Whether that correlation works at scale across thousands of applications is an open question.

Invicti is not alone. On March 18, 2026, at the JavaOne conference, Waratek launched a standalone IAST product that the company claims reports flaws that are exploitable with 100 percent accuracy. The press release acknowledged the pressure from AI-assisted coding, noting that machine-generated code introduces vulnerabilities at a rate that manual review cannot match. Waratek's bet is that runtime instrumentation, not static scanning, is the right layer for finding flaws in code written partly by machines whose output is too voluminous to review line by line.

The competitive landscape reflects the pressure. Snyk, which built its business on developer-first SAST, has been expanding into runtime and AI security. In May 2026, the company launched a services delivery program for channel partners, CRN reported, with an emphasis on securing AI and agentic workloads. Snyk CRO Tom Nielsen told CRN that the program would start with implementation services and build toward "very mature managed services" around the platform. The messaging shift from "scan your code" to "secure your AI workloads" is a signal about where the revenue is expected to come from.

Checkmarx, the long-time SAST incumbent, earned FedRAMP Moderate certification for its Checkmarx One for Government platform on July 14, 2026. The certification matters less as a technology milestone than as an indicator of market structure: the government procurement apparatus now expects application security to arrive as a unified platform, not as three separate line items on a purchase order. When FedRAMP certifies a platform, it certifies the integration.

The convergence raises questions that the press releases do not answer. The first is architectural: a platform that combines SAST, DAST, and runtime analysis is only as strong as its weakest link, and the three functions demand fundamentally different engineering. SAST requires language-specific parsers for every framework in use. DAST requires a crawl engine that can navigate modern single-page applications and API-driven architectures. Runtime instrumentation requires agents that run inside production JVMs, .NET runtimes, and containerised Go binaries without degrading performance. Few organisations have deep expertise in all three. A vendor claiming to offer all three under one roof is making an engineering claim worth scrutinising.

The second question is about the data model. Correlating a runtime exploit back to a SAST rule requires a common representation of vulnerability identity that none of the three categories was originally designed to produce. SAST tools identify flaws by pattern ID and file location. DAST tools identify them by URL and payload. Runtime tools identify them by stack trace and data flow path. Reconciling these into a single finding is a data engineering problem, not a security problem, and the companies that have tried it, Veracode, Synopsys, and others, have spent years on the mapping layer.

The third question is about the realistic attacker. For most organisations, the threat that matters is not the zero-day chain that combines a SAST-missed injection with a DAST-missed authentication bypass and a runtime-visible memory corruption. It is the unpatched known vulnerability in a third-party dependency, or the misconfigured S3 bucket, or the credential checked into a public repository. A unified SAST-DAST-runtime platform that excels at finding novel vulnerabilities in custom code may still miss the exposure that actually causes the incident. The tools that find those exposures, software composition analysis, cloud security posture management, secrets scanning, are not part of the triad.

The entry of Anthropic and OpenAI into application security complicates the story further. Claude Code Security and Codex Security are not platforms. They are single-function scanners that operate on source code. But they are free or nearly free, and they are backed by foundation model providers whose core business is not application security. Their presence in the market changes the pricing and performance expectations for SAST, which has historically been the most expensive component of the triad. If a reasoning scanner can deliver 80 percent of a commercial SAST product's precision at zero cost, the platform vendors must justify their price on the remaining 20 percent, and on the value of integrating SAST with DAST and runtime.

The vendors are already adjusting their language to meet this moment. Invicti's press materials use the phrase "proof-based" repeatedly, a claim that every reported vulnerability has been confirmed as exploitable, whether by dynamic testing or runtime observation. That language is a direct response to the SAST false-positive problem and, implicitly, to the LLM scanners that promise to solve it through reasoning. The word "proof" is doing a lot of work in these documents, and security buyers would be wise to ask what kind of proof, generated under what conditions, and with what assumptions about the deployment environment.

The convergence trend also changes the organisational question. If SAST, DAST, and runtime are separate tools, they tend to be owned by separate teams: application security engineers own SAST, penetration testers own DAST, and site reliability engineers own runtime monitoring. A unified platform collapses those ownership boundaries. The vendor pitch is that this improves collaboration. The reality, in organisations that have already consolidated, is that it shifts power toward whichever team controls the platform contract, and away from the specialists who previously had independent budgets and independent findings.

What to watch for in the second half of 2026: first, whether any major independent SAST or DAST vendor, Synopsys, Veracode, or Contrast Security, makes a platform play that matches Invicti's scope. Second, whether Anthropic or OpenAI extends its free scanner into dynamic testing or runtime analysis, which would fundamentally alter the market structure. Third, and most important, whether the correlation engines that promise to link SAST, DAST, and runtime findings actually produce fewer false positives than running the three tools separately and correlating them manually. The burden of proof is on the platforms, and the metric that matters is not the number of vulnerabilities found but the number of incidents prevented. We do not yet have that data.