Analysis
Govern AI-Augmented Development and Implement AI-Generated Code Remediation
GenAI is reshaping application development, enabling much faster development and presenting new risks. Most engineering leaders (65%) responding to the Gartner Software Engineering Survey for 2025 report that up to half of their software development teams are already employing AI tools to augment workflows,with more expected to adopt not only AI coding assistants but true vibe coding in the near future (see Why Vibe Coding Needs to Be Taken Seriously).2 These tools leverage language models to help developers code faster with minimal effort.
The adoption of AI-augmented software development introduces significant security concerns: 76% of organizations that choose to ban AI-assisted coding do so out of fear of introducing vulnerabilities.4 This concern is reasonable considering the training data for these tools is likely to be vulnerable and, therefore, so would be the output.6 After all, 97% of codebases contain open-source components and 81% of these contain high severity security vulnerabilities (also see How to Secure Software Development in the AI-Driven Era). However, the new AI-assisted and vibe coding tools themselves also present potential exposures and unforeseen behaviors that can lead to security issues.7
While it may not be advisable to experiment with AI-augmented coding on critical applications, cybersecurity leaders should allow the developer population to experiment with AI-augmented software development selectively on less sensitive applications — for example, internal or experimental projects or limited to certain advanced teams of developers. Establishing an AI-generated code security policy and process is key.
In addition to new security concerns, AI-assisted coding exacerbates the problems that come with DevSecOps. AI-augmented coding allows developers to produce more code, faster. The issues that GenAI introduces in that sense can be alleviated with the same GenAI technology: AI code security assistants (ACSAs) act as virtual security champions by providing explanations and guidance about vulnerabilities, and by proposing code remediations. Thirty-percent of organizations using AI have reported improvements in code security.2 These tools can significantly speed up the mean time to remediate (MTTR) vulnerabilities.5 Examples include Checkmarx Developer Assist Agent, GitHub Copilot AutoFix, Mobb, Qwiet AI and Veracode Fix, among others (see AI code security assistants in the Hype Cycle for Application Security, 2025). ACSAs can come as a stand-alone tool, or as a static application security testing (SAST) or software composition analysis (SCA) add-on (see Innovation Insight for AI Code Assistants).
Gartner is observing clients that decide to include ACSAs in their AST renewals (typically after a first-year trial), recognizing both its potential and the fact it still has room to mature. For now, we advise to err on the side of caution and maintain a human in the loop for code remediation suggestions from ACSAs.
Optimize Developer Experience and Streamline DevSecOps Workflows
Fifty-five percent of the engineering leaders in the Gartner Software Engineering Survey for 2024 reported that their software engineering organizations are using code inspections or reviews to improve software quality.3 Application security engineers are mainly responsible for defining the rules and thresholds that need to be applied throughout the development life cycle (see the Sample Job Description for AppSec Engineer [Word download] from the Cybersecurity Job Descriptions Library). As a result of this shift, developers become overwhelmed by the added workload, leading to friction with security teams.
Developer experience is fundamental to streamlining DevSecOps. Application security posture management (ASPM) principles are the key.
There are three main things that ASPM provides to enhance the developer experience: vulnerability prioritization, workflow orchestration and application visibility.
Vulnerability prioritization is a process that integrates several techniques to effectively identify and address the most critical security risks. It involves reachability analysis to determine whether vulnerable third-party libraries are actually used in the code, helping to distinguish between essential and less urgent fixes. The process also includes deduplication of findings from multiple security scanners to minimize noise, and considers whether vulnerabilities are actively being exploited in the wild. Additionally, the criticality of the application — such as whether it is externally facing or vital to business operations — is assessed, alongside the severity of vulnerabilities as indicated by their common vulnerability scoring system (CVSS) scores. Finally, correlating findings from different scanners for the same application further enhances the accuracy of vulnerability assessment and prioritization.
By applying these prioritization techniques, organizations can significantly reduce the number of findings developers need to address (some ASPM vendors claim approximately 75% reduction in findings), making their workload more manageable.
Workflow orchestration translates logical application security policies into technical enforcement directly into the development life cycle. ASPM systems can automate critical tasks, such as requiring signed commits for code integrity, or ensuring that only reviewed changes make it into the codebase. They can also monitor for compliance with policies such as multifactor authentication (MFA) across development tools. ASPM integrates with DevOps platforms and integration/continuous delivery (CI/CD) pipeline components — such as the ticketing systems, issue tracking systems and build servers. Additionally, it can help impose automated actions like failing builds when vulnerabilities exceed severity thresholds, blocking the use of insecure dependencies or creating tickets for remediation. Automated workflows not only reduce manual intervention but also ensure that security best practices are consistently applied across the organization’s software teams and projects.
Visibility with ASPM provides discovery of assets and assignment of issues ownership. ASPM can identify applications and APIs across the organization by inspecting code repositories. One of the persistent challenges in application security is determining which team is responsible for addressing specific vulnerabilities, especially when there are thousands of findings across multiple teams. ASPM aims to map security findings to the appropriate teams. This clarity not only prevents delays but also fosters accountability, ensuring that security issues are promptly assigned and resolved.
Application security posture management is a practice, not a product — but ASPM products can help operationalize this practice.
Gartner has observed large organizations build their own ASPM tools, but most mainstream organizations are likely to either use the ASPM that their AST provides, or go for a stand-alone solution.
Drive Application Security Maturity Through Platform Convergence
Along with ASPM, Software Supply Chain Security (SSCS) is coming into prominence and for good reason: 97% of codebases contain third-party code and 81% of them contain high security vulnerabilities.9 ASPM and SSCS are interrelated, for example:
SSCS controls such as version control and package firewalls can hinder the developer experience that ASPM is supposed to fix.
SSCS controls and compliance checks, such as signed commits and usage of MFA, can be enforced via ASPM tools.
This leads to ASPM providers offering SSCS and vice versa. Additionally, both ASPM and SSCS providers are increasingly adding static code analysis to their offerings, which enables them to compete in an AST-driven market. Therefore, the third main trend shaping application security, and its maturity, is tool convergence. Providers from different backgrounds try to solve the same problem: application vulnerability identification and remediation.
The future of application security is trending toward convergence into a unified application security platform that brings together AST (including SAST, SCA, dynamic application security testing [DAST], and interactive application security testing [IAST]) with ASPM and SSCS. These are products that have security leaders as the main buyer, security practitioners as the main administrator and developers as the main end user.
Figure 2: Convergence of AST, ASPM and SSCS Into a Unified Application Security Platform

Gartner clients often ask whether they should go further and merge their AST with their cloud-native application protection platform (CNAPP) offering. Because the borders between cloud infrastructure and code are increasingly blurry, most application security platform offerings already provide container security scanning, and infrastructure-as-code scanning. CNAPP tools do so as well, and they are increasingly providing application security functionality.8 This increasing overlap will eventually lead to a convergence between CNAPP and application security platforms with providers from both backgrounds, resulting in one common platform that identifies, prioritizes and remediates application and cloud infrastructure vulnerabilities. With one major caveat: shifting left for a security tool means impacting developer experience. Therefore, the convergence will be slowed down because it takes time for traditional security vendors with products intended for security practitioners to “reinvent” their offering for a developer audience. At the same time, a speedier adoption of ACSAs will accelerate this convergence by resolving developer experience issues. Eventually these two forces will balance each other out.
Another related question is whether application runtime security such as web application and API protection (WAAP) will also converge with AST and CNAPP. It is important to note that when it comes to runtime, there is runtime protection and runtime scanning. We are already observing WAAP runtime protection vendors offer API security testing. For now we believe these will remain spot opportunities where sensible rather than full integration. However, runtime scanning will be a central part of this convergence and application security platforms will have to provide this kind of functionality: examples include reachability analysis approaches that use eBPF-enabled runtime scanning (see “Reachability Analysis” in Hype Cycle for Application Security 2025).
Cybersecurity leaders should assess consolidated offerings from all sides with a focus on developer enablement. For offerings from the cloud security space, cybersecurity leaders should ensure they can still support any on-premises use cases they might have (the frame of mind should be “code-to-workload” rather than “code-to-cloud”), either on the same platform or via a stand-alone offering.
To begin a platform convergence project, cybersecurity leaders should first inventory their existing application and cloud security tools to understand their current landscape, identify redundancies and assess effectiveness. Following this, they should identify strategic vendors and key products around which to build an application and cloud security consolidation project. Cybersecurity leaders can use Tool: Cybersecurity Platform Consolidation Workbook to assess their landscape and start this initiative.