AppSec for the AI Era: What's Converged, What's Not
AppSec
AppSec for the AI Era: What's Converged, and What's Still Taking Shape
AppSec vendors have converged on exploitability-scored triage, autofix pull requests, coding-agent integration, and grounded output, making those four things table stakes, not differentiators. Real competitive separation over the next 12 months will happen in four unsolved areas: continuous re-testing after a fix ships, AI-BOM, mobile AppSec keeping pace with embedded AI, and agent guardrails that enforce policy at the execution harness, not just the agent's decisions.
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.
September 16, 2026
By Diogo Rispoli
Application Security
AI
AI Coding
DevSecOps
SBOM
SCA
Compliance
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.
Frequently Asked Questions
Exploitability-scored triage, AI-generated autofix delivered as a pull request, scanning and remediation embedded directly in the IDE or coding agent session, and output grounded in real code context or past triage decisions rather than raw model output. Checkmarx's AI Security Champion, GitHub's agentic autofix, and Semgrep's Assistant Memories are current examples. Any AppSec platform without some version of all four is now behind, not ahead.
An AI Bill of Materials inventories the models, training data, and third-party model or dataset dependencies feeding an AI-enabled application, the same way an SBOM inventories open-source components. Standards already exist through OWASP/CycloneDX AI extensions and SPDX 3.0 AI profiles, but most organizations still don't generate one routinely the way they've learned to with a standard SBOM.
NowSecure's 2026 Mobile App Risk Management Survey found 95% of organizations already run AI inside their mobile apps, but 37% cannot fully see what that AI is doing, and testing of 50,000 apps found 53% contain AI components that slip past conventional app review. Most AI investment from mobile AppSec vendors has gone into testing faster rather than detecting what an embedded AI component is actually doing inside the app.
Agent guardrails are controls that vet or block what an AI coding agent is allowed to do at runtime, including which skills, plugins, or MCP servers it can invoke, before an action executes. They enforce policy on agent behavior itself, which is a different job from triage or autofix tools that act on code, and it's why guardrails are treated as a distinct, fast-growing category in the AppSec market.
Autofix tools like GitHub's agentic autofix or Checkmarx's AI Security Champion generate a proposed code change and open a pull request. Continuous re-testing goes a step further by independently rescanning the deployed application to confirm the fix actually held and tying that result to evidence, which is what StackHawk's Wingman does by pairing autofix inside a coding agent session with an independent HawkScan rescan and commit-level attestation.
Yes. Manifold Security's GitSpawn disclosure, published September 1, 2026, found eight flaws across seven different AI coding agents that let an attacker run arbitrary commands during an agent's background context gathering, before any workspace-trust prompt appeared, by exploiting Git configuration settings. Four of the eight were still unpatched at disclosure. It showed the exploitable surface sits in the execution harness underneath the agent, a layer most funded guardrail products aren't built to enforce, and no vendor-neutral product covers it across different coding agents yet.
Keep Reading
Related Blogs
Explore a few more Merito insights that align with the themes in this article.
