We at Merito ran a recent market analysis across the AppSec products we represent, and the broader vendor landscape around them, pointing to a pattern worth sharing. Every product still carries its own unique set of capabilities, shaped by how each vendor built its platform, but a handful of common themes are now showing up across the market regardless of who built the product. The category is converging quickly around a shared set of AI capabilities, even as the landscape keeps shifting underneath everyone building on it.
Look at what four or five AppSec vendors have actually shipped and announced recently, and the same four capabilities show up almost everywhere: triage that scores exploitability instead of just severity, auto-generated fixes that show up as a pull request, scanning that lives inside the same coding agent session a developer is already running, and recommendations grounded in the actual codebase instead of a generic pattern match. Eighteen months ago, any one of those would have stood out as a feature on its own. Today, it's simply where the category has landed, and it's a good marker for how fast this market is moving.
TLDR: triage, autofix, IDE and coding-agent integration, and grounded output have become table stakes across AppSec vendors. The real competitive separation over the next 12 months is going to happen in four places almost nobody has fully solved: continuous re-testing after a fix ships, AI-BOM, mobile, and agent guardrails.
The intersection everyone converged on
Triage. OpenText was first to market here. Fortify Aviator launched in July 2024 with AI-driven auto-triage that sorts a static analysis finding as a real vulnerability or a false positive, paired with contextualized remediation guidance, full code blocks a developer could act on, though autofix wasn't part of that initial release. Checkmarx's AI Security Champion has since taken a similar approach further, attaching a 0-100 confidence score to each finding, meant to reflect how exploitable the vulnerability actually is in the context of your code, along with a vulnerability explanation and the option to question or push back on the suggestion. Semgrep took a different path to a similar destination with Assistant Memories, which captures triage decisions your team already made, like a closed alert or a "not exploitable" comment, and turns that into reusable context so the same noise doesn't get flagged twice. One Fortune 500 customer reportedly filtered 588 false positives from a single added memory. Different mechanisms, same instinct: stop asking developers to triage a raw severity number and start giving them a ranked, contextualized judgment call instead.
Autofix. GitHub's agentic autofix explores the relevant files across your codebase, proposes a change, reruns CodeQL to confirm the fix actually resolves the alert, and opens a draft pull request with a summary of what it did and why, typically in two to four minutes. Checkmarx's AI Security Champion generates code developers can drop straight into their workflow. Snyk's Agent Fix takes a similar idea and grounds it in a database of more than 35,000 real-world vulnerabilities and prior fixes, then surfaces a pre-screened fix, rated at roughly 85% accuracy, that a developer applies with one click. Microsoft brought a version of the same idea into Azure DevOps. None of these are identical products, but they're solving the identical problem: get a working fix in front of a developer without making them start from a blank file.
IDE and agent integration. Checkmarx built AI Security Champion to live inside the IDEs developers already have open, rather than asking them to context-switch into a separate dashboard. Snyk Code takes the same idea a step earlier, scanning code as it's written and flagging issues inline the moment an AI tool like Copilot generates a suggestion, before it ever reaches a pull request. The pattern across the category is the same: AppSec vendors have stopped trying to pull developers into a security tool and started showing up inside whatever tool the developer is already using to write code.
Grounding. This is the connective tissue for the other three. A confidence score is only useful if it's grounded in something real rather than a plausible-sounding guess. A memory only reduces false positives if it's actually built from your team's past decisions. An autofix only earns trust if it's verified against your actual code rather than a generic pattern. Every vendor above is solving a version of the same underlying problem: raw LLM judgment on a security finding isn't trustworthy by itself, so you wire in confidence scoring, reusable organizational memory, or an independent rescan to ground the output before a human ever sees it.
Why this commoditizes fast
None of this stays a differentiator for long, and it shouldn't surprise anyone that it won't. Once one credible vendor ships exploitability scoring, it becomes a line item on every RFP that follows. Once autofix shows up as a pull request from one platform, procurement starts asking every other vendor in the bake-off why they don't have it too. That's not a knock on any of these products. It's just how competitive categories behave once the first mover proves the feature is buildable and customers start expecting it by default.
Which means the platforms racing hardest to check these four boxes right now are optimizing for parity, not advantage. The interesting question for the next 12 months isn't who ships triage scoring first. It's who's actually working on the problems underneath it, the ones that don't fit neatly into a feature announcement.
Four gaps nobody's closed yet
Continuous re-testing closes a loop autofix leaves open
Most autofix tools stop at the pull request. The agent proposes a change, a human merges it, and nobody independently reruns anything against the live application to confirm the fix actually held once it shipped alongside everything else in that release.
StackHawk's Wingman is the most concrete attempt yet at closing that loop. HawkScan runs inside the same coding agent session as the autofix itself, the agent parses findings and remediates on a feature-complete branch, HawkScan rescans to verify the fix held, and the whole sequence, scan, finding, fix, gets tied back to a commit as a third-party attestation. It's priced at $10 per developer per month for unlimited apps and 50 scans per user per month, which tells you it's built to run constantly rather than as an occasional enterprise scan.
Here's the part worth sitting with, though. A clean rescan proves one specific vulnerability wasn't reproduced against that particular state of the application. It doesn't prove a new vulnerability wasn't introduced somewhere else in the same change, that an architectural invariant didn't break, or that the artifact actually deployed is the one that got tested. Somebody still has to build the layer that stitches SAST, SCA, DAST, and runtime signal together into something stronger than "we reran one scan and it passed." Platforms like Black Duck's Software Risk Manager already correlate findings across 150-plus tools and 20-plus compliance frameworks, which covers the aggregation half of that problem. What's still missing is the other half: an automated verify-and-attest step tied to the specific fix an agent just made, not just a dashboard rolling up whatever scans already ran.
AI-BOM has standards and no muscle memory
The pieces exist. OWASP and CycloneDX have shipped AI-specific extensions, including the OWASP AIBOM Generator, an open-source tool that produces AIBOMs directly from Hugging Face models. The Linux Foundation added dedicated AI and dataset profiles to SPDX 3.0. The OpenSSF AI/ML Working Group formalized a model-signing spec with contributions from most of the major platform vendors. NIST extended its own Secure Software Development Framework with SP 800-218A in July 2024, adding AI-specific practices, for producers of AI models, producers of the systems that use them, and the organizations acquiring them, to the existing SSDF. Checkmarx already sells AI supply chain security scanning, and Saltworks has SBOM delivery built for exactly this kind of governance and compliance work.
What's missing is habit. SBOM took years of regulatory runway, most of it tracing back to Executive Order 14028 in 2021, before most organizations generated one as routine practice instead of a one-off checkbox for a single contract. AI-BOM is earlier in that same curve, pushed mostly by the EU AI Act's August 2026 provisions, the SSDF's AI extension, DoD SBOM mandates, and insurance carriers starting to condition coverage on AI governance documentation, not by AppSec teams generating them because that's simply how software ships now. The model feeding a feature, the training data lineage behind it, and the third-party model a developer pulled off a hub yesterday afternoon are exactly the kind of supply chain risk AppSec already knows how to reason about. Almost nobody has made producing that inventory as automatic as producing an SBOM is starting to feel.
Mobile is still catching up to everything else on this list
Everywhere else in this piece, the story is AI helping secure software faster. In mobile, the more urgent problem right now is that AI shipped inside the app is itself the untested thing. NowSecure's 2026 Mobile App Risk Management Survey found that 95% of organizations already run AI inside their mobile apps, but 37% said they cannot fully see what that AI is doing. Testing across 50,000 apps found 53% contain AI components, many of which slip past a conventional app review entirely.
Most of the AI investment from mobile AppSec vendors so far has gone into testing faster, chat-based querying of a risk graph, broader API access, automation scaffolding, not into detecting what an AI component embedded in the app is actually doing with data, identity, or authorization once it's running. That leaves mobile behind code and API security on both fronts at once: applying AI to make testing faster, and testing the AI that's already shipping inside the apps themselves.
Agent guardrails: the most funded gap, and still the least closed
This is where the money is. Roughly $435M went into agent guardrail and runtime-governance startups across about a dozen financings between April 2026 and September 2026. Zenity raised $125M in a Series C. HiddenLayer raised $100M emphasizing runtime agent protection. AIR raised $50M in seed funding, describing itself as an inline firewall that vets the skills, plugins, and MCP servers an agent tries to use. Cymphony raised $30M around controlling enterprise AI agents. Alice raised $140M focused on AI trust and safety across model labs. Arga Labs raised $10M building digital twins of enterprise software so agents can be tested without touching production systems. Orchid Security and Akeyless both shipped competing identity and authorization products within a day or two of each other in early September 2026.
That's a lot of capital chasing "stop the agent from doing something it shouldn't." And yet on September 1, 2026, Manifold Security disclosed GitSpawn: eight flaws across seven different AI coding agents, including Claude Code twice, Cursor, OpenAI Codex, Goose, Hermes Agent, Qwen Code, and Grok Build, all exploiting Git configuration settings to run arbitrary commands during an agent's background context-gathering, before a user ever saw a workspace-trust prompt. Four of the eight were still unpatched at disclosure.
That's not a knock on any single vendor's roadmap. It's evidence that the exploitable surface right now sits in the execution harness underneath the agent, how it handles untrusted repo content before a human ever consents to anything, not in the agent's decision-making, which is what most of the funded guardrail products are actually built to police. CrowdStrike and Tenable have both started building agent verification and certification programs of their own this year, which narrows the problem without closing it, since each is scoped to its own partner ecosystem. Nobody has shipped a vendor-neutral layer that enforces workspace trust and execution policy the same way across Claude Code, Cursor, Copilot, and whatever ships next month.
What this means for the next 12 months
If you're building an AppSec roadmap right now, budget for the four converged features as hygiene, not strategy. Every serious platform will have exploitability-scored triage, some form of autofix, and IDE-native workflows within the next product cycle or two, whether you push a vendor toward it or not.
Where you actually get to make a call that matters is in the four gaps. Does your fix verification loop produce evidence you'd trust in front of an auditor, or does it stop at a merged pull request? Do you have any real inventory of the models and datasets feeding your AI-enabled applications? Has your mobile program caught up to the fact that the apps themselves now carry AI risk that a standard pentest checklist wasn't built to catch? And do the coding agents your own developers already run every day have any enforcement layer underneath them that isn't just "trust the vendor patched it"?
We'll go deeper on each of these over the next few posts, since each one deserves more room than a section here can give it. This one's meant to be the map, so the apps your teams ship stay safe and secure whichever gap you tackle first.
How Merito helps
This is exactly the evaluation we run inside MAPS Assessment engagements: benchmarking where a program already has the table stakes covered and where it's still exposed on re-testing, AI-BOM, mobile, or agent guardrails specifically.
Our Application Security practice covers the full lifecycle, shift-left code scanning, software supply chain and SBOM, runtime protection, and developer enablement, so we're evaluating these same vendor moves against real customer environments every week, not just press releases. That includes hands-on work with platforms like Checkmarx, Semgrep, Snyk, and Black Duck.
If you want an honest read on where your own program sits against these four gaps rather than the four everyone's already solved, book a scope conversation and we'll walk through it together.
