Black Hat USA 2026 didn’t introduce the AI security problem, but made it clear how fast thatproblem is becoming operational.
An independent study initiated and funded by Checkmarx helps explain why. On real-world repository tasks, frontier models produced working code 83% to 95% of the time, but only 24% to 36% of their solutions were both functional and secure. Adding a post-generation security review improved the secure-and-functional rate to 47% to 56%, but a substantial gap still remains between code that works and code that can be trusted.
That gap changes the role that application security must play. When AI is generating the code, the signals that teams have typically trusted stop working: code that compiles, passes a functional test, or comes with a confident explanation cannot be assumed to be secure. A passing test only confirms the code does what was asked; it says nothing about what wasn’t asked, or what the model never thought to check. And because the system writing the code is often the same class of model asked to review it, an AI system should not be solely responsible for verifying its own output – that isn’t independent verification; it’s the model grading its own homework.
That same tension surfaced throughout Black Hat itself, across the official agenda, research releases, and Business Hall discussions. The keynote program covered cyber power in the age of AI, defense when offensive capabilities become cheaper, and vulnerability research in the agentic age. Although separate, these discussions pointed to one common fact: AI is simultaneously speeding up software creation, vulnerability discovery, exploit development, and security response – and security teams need a way to keep up.
Meanwhile, enterprise applications are accumulating more models, agents, packages, APIs, MCP servers, tools, permissions, and automated decisions. The vulnerabilities themselves are generally familiar. What has changed is the speed at which they can be introduced, discovered, and exploited, along with the number of relationships security teams must understand. The operating model, not the next AI model, has become the real AppSec issue.
When Vulnerability Discovery Becomes Industrial
Research released around Black Hat showed the scale of the change. Palo Alto Networks Unit 42 reported that its NOVA autonomous vulnerability-research system analyzed 3,915 open-source projects over two months and confirmed 14,090 vulnerabilities. Of those, 99.4% were previously unreported, 39.7% were rated High or Critical, and 92% involved semantic or logic flaws such as access-control failures, path traversal, code injection, prototype pollution, and server-side request forgery.
The architecture behind those results matters as much as their volume. NOVA’s strongest results came from an ensemble of models, specialized security tools, structured workflows, and automated validation. Candidate findings were tested with working proofs of concept and replayed in clean environments before being confirmed as vulnerabilities.
That validation step is what breaks down when one model acts as both investigator and judge, results are less reliable and have weaker coverage. Research covered by Dark Reading showed general-purpose LLMs still struggle with false positives, reachability, prioritization, and application context.
In security, a fluent answer remains a hypothesis until evidence supports it. AI can expand reach and accelerate action, but trustworthy security still requires independent validation, application context, policy, and accountability.
“AI provides real, tangible benefits to security teams. What AppSec leaders are underestimating—but beginning to recognize—is how difficult it can be to move from an internal proof of concept to an enterprise-scale deployment. It is relatively easy to build something that works on one laptop. Making it work consistently across a 10,000-person organization is much harder. Organizations can see the value; the challenge is capturing that value at scale.” – Frank Emery, Senior Director of Product Management
Meeting that challenge at enterprise scale calls for a three-part operating model: capture complete software risks you can trust at predictable cost; unify risk intelligence with governance and enforce it; and eliminate attackable risk at machine speed through triage, remediation, and prevention at the point of creation.
Capture Complete Software Risks You Can Trust, at Predictable Cost
Applications still contain legacy code, third-party components, complex business logic, and vulnerabilities that emerge only when several parts of a system interact. Detection therefore needs two qualities that are often treated as a tradeoff. It must reach beyond fixed rules to identify new and complex vulnerability classes while still producing results that security teams can reproduce, explain, and defend.
That requirement is already met by Checkmarx’s hybrid model: a deterministic engine and an AI-reasoning engine analyze code in parallel, and a Findings Analysis Engine reconciles their output into one verified result — precise, broad, and repeatable on every scan. That hybrid model is the foundation powering Next-Gen SAST today.
Checkmarx Fusion, announced in early access ahead of Black Hat, builds on that foundation even more. Its Multi-Model AI Engine runs several curated frontier models on top of the hybrid model’s already-reconciled, already-validated findings — reasoning over that same verified result set from a different vantage point to surface what the hybrid model was never built to catch: vulnerabilities with no known rule, CVE, or signature to match against.
That layering is also what keeps cost predictable. The hybrid model runs on every scan as standard, included capability. Fusion sits on top as an optional, usage-based layer, drawing on a bounded set of research-validated models rather than open-ended frontier API calls — teams choose higher- or lower-cost models per project, so reaching further for novel and AI-generated-code vulnerabilities doesn’t mean an unpredictable token bill on every commit.
Unify Risk Intelligence and Governance…and Enforce It
An AI agent is more than a model. Its behavior is shaped by its prompts, memory, tools, packages, APIs, permissions, MCP servers, and operating environment. Research into security weaknesses within AI harnesses shows that risk frequently emerges at the handoffs between these components, even when individual technologies have their own safeguards.
Orchestration is therefore a governance issue, not simply a workflow-automation problem. Enterprises need to know which AI components exist, where they entered the development lifecycle, what data and tools they can access, whether they comply with policy, what actions they have taken, and which decisions were reviewed by people. Checkmarx AI Inventory and AI-BOM use deterministic analysis to identify models, agents, MCP servers, AI libraries, and SDKs across repositories. Findings are traceable to specific files and lines of code, enabling teams to enforce policy at commit and generate versioned AI-BOM documentation for each release.
At the broader application-risk level, Checkmarx One Risk Orchestration correlates signals from SAST, SCA, infrastructure-as-code security, API security, secrets detection, containers, repository health, DAST, and third-party tools. It then enriches those findings with exploitability, reachability, exposure, ownership, and business criticality. With trusted findings feeding a shared risk model, governance can move from policy on paper to consistent enforcement across pull requests, builds, and releases. Checkmarx Fusion strengthens the evidence entering the system. Risk Orchestration connects that evidence to applications, policies, owners, and action. AI Inventory brings the AI components embedded in applications under the same governance model.
Eliminate Attackable Risk at Machine Speed: Triage First, Then Remediate
Faster detection creates a downstream problem: more findings competing for finite remediation capacity. No organization can manage AI-scale vulnerability volume by treating every High or Critical alert as equally urgent. Severity describes potential impact, but it does not establish whether vulnerable code is reachable, whether the flaw is exploitable in this application, what mitigating controls already exist, or how important the affected application is to the business. Attackability provides that missing context.
Checkmarx Triage Assist and Remediation Assist apply AI reasoning to eligible SAST and SCA findings while grounding decisions in reachability, exploitability, code context, risk context, policy, and mitigating controls. Triage Assist helps distinguish findings that require action from acceptable risks and suspected false positives. Remediation Assist then provides review-ready guidance and suggested code changes for the risks that matter.
For supported GitHub Code Repository Integration projects, Checkmarx can create a separate pull request containing the proposed fix for developer review and approval. Nothing is merged automatically. Developers retain final approval and accountability, while AppSec teams preserve policy control and a record of the risk decision.
Eliminating attackable risk also requires preventing the backlog from continually refilling. When an AI coding agent can modify files, install packages, and refactor an application, damage can occur before code reaches a repository or pipeline. A malicious package may execute during installation, while a vulnerable pattern can spread across several files before anyone reviews the change.
Waiting for a downstream scan is no longer sufficient. Prevention must operate where human developers and coding agents create software. Checkmarx Developer Assist brings real-time scanning, application-security context, and remediation into IDEs and AI coding workflows. Its autonomous mode uses hooks and MCP to intercept actions such as file writes and package installations, evaluate them before they take effect, and return remediation information directly to the coding agent. The security decision comes from an independent AppSec layer, not the system that generated the code. Triage and remediation drain the existing pool of attackable risk; prevention at the point of creation stops that pool from growing again.
What Comes Next: Context Becomes the Control Layer
The next stage of agentic AppSec will be shaped by the quality of context available to every security decision. That context must connect code, dependencies, architecture, runtime exposure, asset ownership, business criticality, policy, remediation history, and previous approvals. Without it, agents work from incomplete snapshots, repeat analysis, and reach conflicting conclusions about the same risk. With shared context, organizations can capture a complete, trustworthy view of software risk; unify that intelligence with enforceable governance; and eliminate attackable risk at machine speed. Triage and remediation drain the existing backlog, while prevention at the point of creation stops it from growing again.
AI has made action cheap. Context will determine whether that action is correct. The organizations that lead in this environment will not necessarily be the ones using the most AI. They will be the ones with the shortest, most defensible path from code to evidence, action, and accountability.
Turn AI Speed Into Governed Security
See how Checkmarx One helps organizations capture complete software risk they can trust, unify risk intelligence with enforceable governance, and eliminate attackable risk at machine speed.
AI
AI generated code
AI in Cybersecurity
AppSec