Summary
Application Security has long evolved around embedding security checks throughout the SDLC, centered on SAST, DAST, and SCA. While this approach was effective at broadly finding vulnerabilities, the real bottleneck in practice has always been determining “what is actually a real problem.” The fundamental structure of secure development as defined by NIST SSDF also focuses on internalizing security controls across development stages, and in reality, operational costs have often grown more from triage and remediation coordination than from detection itself.
Around RSAC 2026, this market is being rapidly reshaped. Snyk introduced AI Security Fabric and Secure at Inception, Checkmarx declared agentic application security, Apiiro and Cycode emphasized code-to-runtime context, AI guardrails, and agentic development security, while HCL and OpenText put MCP-based AI integration front and center. In short, the AppSec market in 2026 has moved from a “better scanner” competition to a “control plane that prevents, analyzes, prioritizes, remediates, and governs at AI speed” competition.
However, the verification discussed in this report differs from what the market commonly describes — “AI reads it once more,” “attaches more context to calculate an exploitability score,” or “re-checks whether a fix is correct.” The verification we refer to is generating a PoC, executing it against the target service or an equivalent verification environment, and proving the existence of the vulnerability through execution results. OWASP has warned that over-reliance on LLMs can lead to hallucinations and incorrect recommendations, and 2025 research has also pointed out the limitations of false positives and false negatives in LLM-based vulnerability triage, emphasizing that critical oversight by human analysts remains necessary.
Conversely, PoCs have long been treated in the security industry as “code or attack demonstrations showing that a vulnerability is actually exploitable.” CISA describes a PoC as “code that, when executed, permits exploitation,” and CVSS/NVD treats the existence of PoC exploit code as an important stage of exploit maturity. Text-based LLM judgments still require humans to review “whether this explanation is correct,” but when a PoC is actually executed and a vulnerability is reproduced, the basis for verification shifts from “the model’s claim” to “the system’s observed result.” This difference is the essence of the verification that Provally focuses on.
How Was Application Security Done Before?
Traditional Application Security was fundamentally a detection-centric market. SAST statically scanned code to broadly detect potential flaws, DAST performed attack simulations against running applications, and SCA identified known risks in open-source dependencies. This structure was effective at finding vulnerabilities early in development and reducing remediation costs, but it was also a structure that pushed massive volumes of alerts and false positives onto AppSec teams.
An important point is that “execution-based verification” wasn’t entirely absent in the past. DAST was originally an approach to find exploitable vulnerabilities in running applications through live attack simulation, and penetration testing was also work that proved risk by reproducing actual attack paths. However, these were generally runtime discovery tools, not a verification layer that took individual SAST results, generated PoCs, and left evidence of whether each finding was truly exploitable.
What Changed After AI?
AI is fundamentally changing the speed of this market. As code generation speed increased, market interest shifted from “how many can we find” to “can we prevent, organize, fix, and prove risks at the same speed as development.” Snyk says it will embed guardrails from the moment code is generated through Secure at Inception, Semgrep released Multimodal combining AI reasoning with rule-based analysis, Checkmarx declared agentic AppSec executing triage and remediation within PRs, and Cycode emphasized AI Guardrails controlling prompts, files, and tool calls at the IDE boundary.
But the key point here is that even though the market has started using the word “verification” more frequently, its meaning mostly remains at re-reading, prioritization, and operational automation. Anthropic’s case and Snyk’s mention of deterministic validation show that the industry already recognizes the problem: “trust formation is slower than the speed at which AI finds things.”
Changes Among Traditional Vendors
Traditional vendors haven’t abandoned their existing AST portfolios. Instead, they’re moving to strengthen precision, triage, remediation, and governance by layering AI on top of their existing large install bases, policies, compliance, and auditability.
Veracode
In 2026, Veracode reorganized its RSAC messaging around AI precision, application risk governance, AI remediation, and supply chain security, putting “Prioritize, Protect, Prove” front and center. However, Veracode’s ‘prove’ here is closer to strengthening due diligence and governance evidence than to executing findings as PoCs for proof.
Checkmarx
In 2026, Checkmarx declared agentic application security through Triage Assist, Remediation Assist, Developer Assist, and Attackability. Attackability in particular considers attacker-controlled input, ingress points, and control effectiveness to better assess “actual attack feasibility.” However, this is still essentially contextual exploitability analysis.
OpenText Fortify
Fortify launched Application Security Aviator offering finding classification, false positive suppression, explainable results, and auto-remediation. Since late 2025, Fortify MCP Server has connected Fortify capabilities to AI agents. The core remains scan result auditing, which is different from a verification layer that proves results through execution.
Black Duck
In 2026, Black Duck launched Signal, emphasizing that AI-native security assesses risk, validates findings, and automates remediation. This is clearly a message that has evolved one step beyond the traditional platform.
Changes Among Emerging Vendors
Emerging vendors are moving faster than traditional vendors from scanner companies to control plane companies. They’re pushing developer-first, workflow integration, and AI-native prevention to capture code authoring, PRs, IDEs, and AI agent workflows.
Snyk
In 2026, Snyk expanded its scope to the entire AI lifecycle with AI Security Fabric, Agent Security, and Evo AI-SPM. Notably, Snyk publicly stated that “enterprise trust still depends on deterministic validation.” This expression is very significant. However, the validation Snyk refers to is deterministic validation for policies, governance, and continuous control — not proving individual findings through PoC execution.
Semgrep
In 2026, Semgrep further evolved with Cursor Plugin, MCP server, Hooks, Skills, Autofix, and Multimodal to scan AI coding agent outputs in real-time and combine AI reasoning with rule-based analysis. This is a case of elevating “judgment automation” to a very high level. However, it is not a model that leaves execution-based evidence.
Apiiro
In 2026, Apiiro moved toward secure-by-design, compliant-by-default with Guardian Agent and AI Threat Modeling at the pre-code-generation stage. While powerful at interpreting static findings more intelligently, this is clearly distinct from verification that proves vulnerability existence through PoC execution.
Cycode
In 2026, Cycode presented the Agentic Development Security Platform, Context Intelligence Graph, and AI Guardrails, proposing a structure that controls stages before prompt submission, file attachment, and tool call execution. However, Cycode’s exploitability is also context-rich inference and orchestration.
Changes Among Startups
Startups enter with relatively narrower wedges but are approaching the verification problem most closely. This is because they directly tackle topics like business logic, exploitability, autonomous pentesting, and verified closure.
Gecko Security
In 2026, Gecko Security clearly argued that static analysis structurally misses business logic vulnerabilities. In the Cal.com case, they demonstrated chained vulnerabilities and account takeover, emphasizing the need for semantic reasoning beyond simple pattern matching.
Cogent Security
Cogent puts connect & normalize, prioritize with context, drive remediation, prove & report, context-to-decision-to-action-to-validation front and center. However, Cogent’s validation is essentially remediation closure validation. Provally addresses the earlier question of “was this finding real in the first place.”
Endor Labs
In 2026, Endor Labs defined AURI as the “missing security intelligence layer,” aiming to see how code from AI coding agents connects to application architecture. They are a player that strongly recognizes the importance of execution proof.
Aikido Security
In 2026, Aikido Infinite put “pentest every release, validate exploitability, generate patches, retest fixes” front and center. Among the startup group, this is the closest message to execution.
Why the Market Still Misses ‘Verification’
The key finding from this survey is that the verification the market talks about effectively splits into three types.
AI Re-reading
A model reads the finding once more and classifies it as true/false
Context-based Inference
Calculates exploitability using code-to-runtime context
Remediation Verification
Checks whether it was fixed and whether retest passed
But the verification Provally refers to is different from all three. It is execution-based finding proof — proving “is this finding actually exploitable?” through PoC code generation and execution results.
There are both technical and business reasons why this isn’t yet at the center of the market. Technically, it requires handling PoC synthesis, safe execution environments, rollback, side-effect control, result interpretation, and reproducibility together, making it highly complex. From a business perspective, most existing vendors are optimized for the scan → prioritize → fix → report flow.
The Problem Provally Is Solving Now
The problem Provally is solving is the last bottleneck after detection, where humans must re-establish trust. That is, taking noisy findings from existing SAST tools, generating a PoC for each finding, actually executing it, and leaving observable evidence that the vulnerability exists. Provally’s answer to this challenge is AutoProof — a product built to automate this entire proof-of-exploitability pipeline end to end.
The essence is converting probabilistic judgment into executable evidence. At this very point, Provally is performing trust conversion, not triage automation.
The Changes This Approach Brings
- Security engineers shift from being people who re-read LLM explanations to people who review execution results and evidence.
- Communication with development teams changes from “it’s theoretically risky” to “here’s how it was actually reproduced.”
- Prioritization, remediation, and governance all operate on more trustworthy inputs.
The security market in 2026 is already mass-producing results across code, open source, IaC, containers, APIs, and AI assets. As every tool moves toward generating more findings, the market needs a higher-level verification layer that converts those findings into “is this actually an exploitable risk.” Provally starts as a SAST verification layer and will expand long-term into a security proof layer.
In Conclusion
The Application Security market at RSAC 2026 is clearly evolving. But the core of that evolution is not “AI finds more vulnerabilities” — it’s “who can make the results generated at AI speed more trustworthy.”
- Traditional vendors are strengthening precision, governance, and remediation. However, the verification they refer to is largely in the sense of auditing, prioritization, and reporting.
- Emerging vendors are trying to capture the control plane through secure at inception, AI guardrails, code-to-runtime context, and exploitability inference. But most of this is still a process of creating better judgments, not a process of proving through execution.
- Startups are approaching harder problems like business logic, autonomous pentesting, and verified closure. But there is still almost no general-purpose proof layer that sits on top of all existing noisy findings.
- Therefore, the key competition going forward is likely to be not “what can find more” but “how quickly can you prove what is actually exploitable through PoCs and execution results.” From that perspective, Provally’s SAST verification layer can be seen as the starting point of the trust infrastructure that AI-era Application Security will inevitably need.