Hype Cycle for Secure Software Engineering 2026
2 June 2026 - ID G00847347 - 83 min read
By Aaron Harrison
Secure software engineering faces rising risks from AI-driven development, modern architectures and complex supply chains. This Hype Cycle helps software engineering leaders embed security into developer workflows, improving DevEx while delivering inherently more secure software at scale.
Analysis
Software engineering faces rising risk from AI-driven development, increasingly complex modern architectures that introduce more distributed components and dependencies, and interconnected supply chains. This Hype Cycle helps software engineering leaders embed security into developer workflows to improve DevEx and reduce risk at scale.
What You Need to Know
Security built directly into development workflows is quickly becoming the dominant form of creating secure software, delivering faster risk reduction and scalable resilience as development expands across human and AI creators.
However, secure software engineering is at an inflection point as AI-augmented development accelerates delivery, and traditional security approaches built on stand-alone tools, scans and gates struggle to keep up. While many innovations in this Hype Cycle still appear as tools, their role is evolving from isolated capabilities to embedded, workflow-native functions within the SDLC.
For software engineering leaders, the message is clear: Progress will not come from buying more tools alone. Use this Hype Cycle to reframe secure software engineering around outcomes and align tools, workflows and teams to make security the default way software is built.
The Hype Cycle
The Priority Matrix
The 2026 Hype Cycle for Secure Software Engineering is defined by a shift from tool-centric security to workflow-embedded, AI-aware protection, with many transformational innovations delivering value over a five- to 10-year horizon. This reflects the rapid rise of AI-augmented development, increasingly distributed architectures and interconnected software supply chains that expand the attack surface faster than traditional controls can scale. Software engineering leaders can accelerate adoption by making secure development the path of least resistance. Embed low-friction security directly into IDEs and pipelines, automate guardrails with policy-as-code and deliver real-time, in-flow security guidance. By reducing toil and complexity, developers can move fast while staying secure by default.
Early wins will come from low-friction integrations that improve developer experiences while reducing risk.
In the near term (one to three years), workflow-native security capabilities such as platform engineering, Al-augmented testing, API security testing, secure coding training and software supply chain security offer the highest value.
These innovations primarily impact developers, platform engineers and security teams by shifting security left and automating routine risk mitigation. Over the midterm (three to five years), roles will evolve as AI agents deepen development participation, requiring new governance and oversight functions. To gain competitive advantage, leaders must prioritize outcome-driven security strategies that make secure development the default, enabling faster delivery with scalable resilience.
Priority Matrix for Secure Software Engineering 2026
| Benefit | Years to Mainstream Adoption | |||
|---|---|---|---|---|
| Less Than 2 Years | 2 to 5 Years | 5 to 10 Years | More Than 10 Years | |
Transformational | ||||
High | ||||
Moderate | ||||
Low | ||||
Source: Gartner
On the Rise
Guardian Agent
Analysis By: Avivah Litan, Daryl Plummer, Tarun Rohilla
Benefit Rating: High
Market Penetration: Less than 1% of target audience
Maturity: Emerging
Definition:
Guardian agents supervise AI agents and help ensure their actions align with goals and boundaries. They monitor and block risky actions and are evolving from a collection of services to autonomous agents that enforce policies across platforms. Guardian agents are transitioning from human-directed automated oversight services into semiautonomous or fully autonomous agents that formulate and execute action plans, and redirect or block actions to align with intended agent goals.
Why This Is Important
- AI agents make deliberate choices — introducing new risks beyond traditional AI, such as complex event chains and interactions within and beyond organisational boundaries.
- These new risks are often invisible and hard for humans or systems to stop, especially as agents scale and gain complexity.
- Automation is critical to monitor, align, and control AI agents, especially as they interact with each other, since human intervention alone cannot scale.
Business Impact
- Safety and compliance: Vital for high-stakes and regulated sectors (e.g., finance, healthcare, legal, government) needing trustworthy, transparent and compliant AI at scale.
- Automated oversight: Human oversight can’t keep pace; automated risk detection/blocking, policy enforcement and auditability required for safe autonomous scalable AI.
- Competitive edge: Early tech-savvy adopters are driven to manage rising risks amid rapid agent growth, to avoid failures and gain competitive edge via reliable AI.
Drivers
- Lack of trust: Organizations hesitate to deploy AI/ML and GenAI for critical processes due to concerns about safety, ethics, and reliability. Guardian agents build trust by providing oversight and assurance.
- AI agency: As LLM-based AI agents gain autonomy to act with or without human involvement, the risk of unintended or unsafe actions rises, driving the need for robust, automated controls.
- Rapid acceleration: The proliferation of AI agents outpaces what human oversight alone can manage. Guardian agents automate governance, ensuring scalable, consistent monitoring and intervention.
- Guardian agents blend AI governance with runtime inspection and enforcement, leveraging AI techniques to monitor, control, and secure AI applications and agents as part of the AI TRiSM framework.
- Vendor lock-In potential: To ensure flexibility, support cross-cloud and hybrid compute and data environments, and support for enterprise-specific policy enforcement, guardian agents must remain independent of specific AI platforms or tools, complementing rather than duplicating built-in governance features.
- Need for versatility: Effective oversight requires a combination of agentic and non-agentic mechanisms to govern both agentic and traditional AI outputs and actions, supporting comprehensive risk mitigation and compliance.
Obstacles
- Trust in guardian agents themselves: As enterprises deploy guardian agents, it becomes essential to implement robust controls to prevent misalignment, security breaches, and operational risks from the guardian agents themselves.
- Skills shortage: Limited expertise in developing agentic and guardian AI systems delays progress.
- Implementation: Few APIs and integration tools hinder effective deployment.
- SaaS integration: Guardian agents are still immature, and can generally not yet support in-line and real-time blocking controls.
- Complexity: High intricacy increases risk of errors and inefficiency.
- Evasion: Advanced agents may bypass detection, requiring ongoing mitigation.
- Fairness/ethics: Defining these controls is subjective and challenging.
- Overconstraint: Excess caution can limit usefulness.
- Overreliance: Users may become complacent, needing education on limitations.
- Vendor hype: Overstated claims can create unrealistic expectations.
User Recommendations
- Launch a cross-functional initiative to systematically discover, inventory, map and manage all AI agents — sanctioned and unsanctioned — across the organization.
- Trial emerging guardian agents now to gain early expertise in safely overseeing increasingly autonomous AI systems, securing a lasting competitive advantage as these tools evolve into mature, full-scale automated AI overseers.
- Invest in emerging guardian agents that aid in continuous AI agent discovery, access management, assurance, monitoring, and improvement.
- Prioritize GA solutions independent of AI agent platforms to; ensure cross-cloud governance, full enterprise information governance and avoid vendor lock-in. Independent solutions should integrate with and complement GA solutions embedded in AI agent platforms for optimal coverage and results.
- Implement meta-governance controls for guardian agents themselves to mitigate their own risks of deviant or destructive actions and behavior.
Sample Vendors
Amazon; Google; Lumia Security; Microsoft; Noma Security; Virtue AI; Wayfound; Zenity
Gartner Recommended Reading
Agentic Coding Security
Analysis By: William Dupre, Jason Gross, Dionisio Zumerle
Benefit Rating: High
Market Penetration: 5% to 20% of target audience
Maturity: Emerging
Definition:
Agentic coding security is focused on securing software development and deployment utilizing automated AI agents for generating code. To meet established cybersecurity standards, agentic coding requires rigorous security verification and visibility. This comprehensive verification process includes application security testing, software supply chain security, agent activity monitoring, prompt sanitization and the security of the underlying technology supporting the AI coding agents.
Why This Is Important
Agentic coding is a set of practices for software development using AI agents, with varied levels of human intervention. Using agentic coding in software development processes has clear benefits, especially for improving team productivity. However, it does carry risks related to application and software supply chain security, such as insecure code, sensitive data exposure, and third-party component misuse. Agents may also be granted excess privileges that allow them to perform insecure actions.
Business Impact
Agentic coding is fundamentally reshaping enterprise software development by accelerating software creation and delivery, and enabling innovation, even as it introduces substantial cybersecurity risks. Agentic coding security will enable this innovation and productivity while providing protection for the development and delivery of business capabilities.
Drivers
- Agentic coding methods use large language models (LLMs) that are often trained on datasets containing code not optimized for security. This can lead to agents reproducing insecure code and introducing critical flaws such as hard-coded secrets, weak authentication, and injection vulnerabilities.
- Agentic coding is enabling development teams to innovate and produce code at speeds and scales that can overwhelm existing application security practices.
- Automated agentic coding workflows challenge existing application security practices, such as point in time security scanning. Integrating agentic coding security practices at the time of the agentic code creation enables cybersecurity teams to align with the new coding patterns, rather than conflict with them.
- Unverified or vulnerable open-source packages and frameworks can be imported by agentic coding solutions, significantly expanding the software supply chain risk by introducing vulnerable or malicious dependencies.
- Technologies like model context protocol (MCP) servers support agent capabilities, but introduce cybersecurity concerns. Such technologies may not have proper access controls in place, and may have unapproved access to tools and services internal and external to the organization.
Obstacles
- Organizations are already inundated with application security vulnerabilities even before introducing agentic coding. This has created cybersecurity debt that will only build up as development velocity increases with agentic coding.
- Short-staffed security teams struggle to keep up with development teams that want to innovate with new agentic coding technologies and patterns.
- Agentic coding patterns like “vibe coding” enable software development without formal methods such as design creation, code reviewing or security verification. An agent is just prompted until a working application is developed. While recommended only for prototyping, vibe coded applications will work their way to production without proper security verification.
- Agentic coding tools are emerging with key cybersecurity features missing. This includes the ability to centrally harden the agentic coding tool configuration, or to easily integrate cybersecurity practices in agentic coding skills and subagents.
User Recommendations
- Establish organizational standards for using agentic coding and enforce compliance with automated application security controls.
- Ensure development processes include a human in the loop where it is relevant for high-risk development activities. Development teams should act as orchestrators and reviewers, not passive participants.
- Gain visibility into the tools being used for agentic coding, including an inventory of agents and the technologies that support them (e.g., MCP servers).
- Implement the principle of “least agency” for coding agents. They should never have unfettered access to sensitive systems and should only have the minimum permissions to perform specific tasks.
- Ensure standard application security practices are in place. This includes application security testing, software supply chain security, and runtime application protection.
- Continuously monitor agent activity, their interactions and supporting agentic technology. Monitor API usage and access to internal/external tools.
Sample Vendors
Archipelo; Backslash Security; Git AI; HCLSoftware; Knostic; Legit Security Ox Security; Secure Code Warrior; Snyk; Symbiotic Security
Gartner Recommended Reading
AI Agent Communication Protocols
Analysis By: Keith Guttridge, Gary Olliffe
Benefit Rating: High
Market Penetration: 1% to 5% of target audience
Maturity: Emerging
Definition:
An AI agent communication protocol is a specification that defines the rules, formats and procedures to enable an AI agent to interact with its environment or with other agents. Unlike conventional APIs or GUIs, which were designed for human understanding, these protocols are designed for AI system use. The two most popular examples are Model Context Protocol (MCP) and agent-to-agent protocol (A2A).
Why This Is Important
AI agent protocols are essential for connecting AI agents and the environment in which they operate. By standardizing communication, these protocols allow AI agents to collaborate with agents running on other platforms, access data from multiple sources and execute tasks from any provider. This interoperability is critical for scaling enterprise AI agent implementation and adoption. MCP’s rapid adoption is driving much of this hype, with A2A trailing a distant second.
Business Impact
AI agent communication protocols help unlock the AI agent potential. By providing AI-focused protocols to enable agent-to-environment and agent-to-agent communication, enterprises will enable greater interoperability between their AI agent technologies and their existing enterprise information technology investments.
Drivers
- Agent-to-environment communication: Standards such as MCP and the more recent Universal Tool Calling Protocol (UTCP) look to establish a common language and structured formats for AI agents to connect to a wide range of applications and data sources. More specialized protocols such as Agents Payment Protocol (A2P), Trusted Agent Protocol (TAP), Agentic Commerce Protocol (ACP) and x402 are emerging for commerce use cases.
- Agent-to-agent communication: Standards such as A2A and increasingly MCP, allow AI agents built on different platforms to collaborate across diverse systems and organizational boundaries. AI agents can advertise their functions and capabilities through standardized descriptions, making it easier for other agents to find and use their services and promoting the creation of modular AI components that can be easily integrated.
- Agent-to-human communication: MCP Apps and Agent User Interaction Protocol (AG-UI) are nascent standards to enable AI agents to influence how user experiences may be rendered for AI agent interaction.
- Improve operational oversight: Standards such as OWASP Agent Observability Standard (AOS) are emerging to help with AI agent observability and enable insight into agentic processes
- Enhance security and trust: Protocols define robust mechanisms for secure interactions, such as authentication, encryption and privacy-preserving techniques, ensuring that sensitive data is protected even when agents operate across different entities or security domains.
- Reduce development complexity and costs: Protocols offer standardized interfaces and methods for agent interactions, which minimizes the need for developers to build custom integrations for every tool or agent, thereby simplifying development and lowering maintenance expenses.
Obstacles
- New standards are emerging: As new standards emerge to solve AI agent pain points, existing standards may fail due to lack of adoption. The best technical solution does not always win.
- Rapid standard evolution: Each new version evolves to address capabilities weaknesses that early adopters had to work around. Managing change across a single protocol is complex. Managing change across multiple protocols may be too challenging for some organizations.
- Poor quality implementations: Ultimately, it is the quality implementation of the standard that determines success, not the specification. Poorly implemented protocols can cause a lack of trust in the specification as a whole.
- Lack of supporting tools: Many of the protocols focus on the AI agent interaction pattern in a point-to-point fashion and forget about management features such as registration, discovery and access policies. This is often left to the vendor community to fill the gaps.
User Recommendations
- Adopt MCP for connecting AI agents to their environment in the short term. While UTCP might seem more logical for existing APIs, adoption of the standard is yet to take off.
- Treat A2A with caution. While this might seem the most popular protocol for interagent communication among the vendor community, the ubiquity of MCP places future iterations of MCP at an advantage for interagent use cases within enterprises.
- Insist on using OpenTelemetry (OTel) for observability at a minimum, and investigate emerging standards for AI agent and large language model (LLM) observability.
- Review AI agent protocol for security risks and build mitigations around known threat patterns. Check each implementation for adherence to the standards.
- Focus on AI gateways to govern your chosen protocols. Agent registries, API registries, MCP registries and model registries will help manage your AI agent environment.
Sample Vendors
Anthropic; Coinbase; Google; Microsoft; OpenAI; Salesforce; Stripe; The Linux Foundation
Gartner Recommended Reading
Policy as Code
Analysis By: Paul Delory
Benefit Rating: High
Market Penetration: 5% to 20% of target audience
Maturity: Emerging
Definition:
Policy as code (PaC) languages express governance and compliance rules as code, so they can be enforced programmatically by automation tools. PaC languages are often domain-specific and declarative. With PaC, policies are treated as software, making them subject to version control, code review and functional testing. The most mature PaC tools can render any business logic in code. You can use PaC today to enforce infrastructure compliance, authorization, Kubernetes admission control and more.
Why This Is Important
Platform engineers use PaC to build optimization, governance and compliance controls into automation pipelines. Infrastructure and security teams have used it for years to build guardrails around infrastructure and data while preserving a separation of duties that mirrors a typical IT organization chart. With the rise of generative AI (GenAI), PaC is poised to become a way to control AI agent behavior and enforce standards programmatically, which current GenAI tools often struggle to do.
Business Impact
- Security, compliance and automation: PaC, combined with automation, enforces policies with implicit compliance guarantees.
- Alignment of security and operations teams: PaC allows security and operations teams to interface directly with automation pipelines.
- Visibility and auditability: PaC documents policies. PaC tool logs can be audited to prove policies are being enforced.
- Time and effort spent: PaC means less toil for operators because it forestalls configuration drift and out-of-spec elements.
Drivers
- Agentic AI: AI agents can make writing and enforcing policy as code easier. PaC tools often require the user to write policies in a dedicated logic language. But an AI agent trained on existing natural-language policy documentation could make effective enforcement decisions with much less effort. The relationship between AI agents and PaC is symbiotic. PaC can provide both effective control and meaningful testing and auditing of agents’ outputs. It can help manage AI agents even as AI agents write policy.
- Government focus: New government initiatives, most prominently the EU’s Interoperable Europe Rules-as-Code, require machine-readable policy definitions. Worldwide, new regulations continue to increase both the difficulty of compliance and the pressure on compliance teams. PaC allows compliance teams and auditors to document their policies in detail and verify that they are being enforced.
- Continued growth of DevOps and DevSecOps: As more companies are embracing DevOps and DevSecOps, they are also encountering the hard governance problems of automation. Many teams that implement infrastructure as code quickly find that they need better policy enforcement, and PaC can help.
- Cloud optimization and cost control: Besides their benefits for security and compliance, PaC tools can also be used to enforce the build standards for infrastructure, including budgets. In the public cloud, where oversized or unnecessary infrastructure incurs direct out-of-pocket costs, programmatically enforced policies can help to control spending.
Obstacles
- Scarcity of community-generated content: PaC tools will not gain traction until they have extensive libraries of community-generated content from which users can download the policies they need rather than having to write their own. Over time, as the user base expands, PaC tools will reach a critical mass of downloadable content that supports real-world uses.
- Skill set: Many technical professionals lack the skills to operate PaC tools effectively. As the learning curve might be steep, you may need to accept some flubbed policy enforcement due to lack of experience.
- Integration challenges: Integrating with existing tools is complex and often requires additional configuration.
- Organizational inertia: In some organizations, collaboration between infrastructure and operations teams and security or compliance teams is actually unwanted. This dynamic may slow the rate, scope and scale of PaC initiatives.
- Costs: Even if PaC tools themselves are free, you need support, training and/or consulting.
User Recommendations
- Start small: Choose a pilot use case where PaC will likely provide real business benefits, then expand to others once PaC has proven its value.
- Upskill staff: PaC languages are not always intuitive. Technical staff will need practice and/or training. Adopt the four-eyes principle to prevent flawed policies from impacting operations.
- Promote reusability: Focus your PaC efforts on use cases that have ready-made implementation templates — ideally, downloadable content. For example, almost every PaC tool on the market has a canned implementation of the customer information systems benchmarks.
- Integrate PaC into automation pipelines: Use PaC to build guardrails for automation tools, so that they cannot take actions that are out of compliance.
- Measure before and after: Use observability tools and value stream mapping to define your starting state, then compare it to the end state. Collect real data to quantify the value of PaC.
Sample Vendors
HashiCorp; Palo Alto Networks; Progress Software; Pulumi; Styra
Gartner Recommended Reading
AI-Native Software Engineering
Analysis By: Manjunath Bhat, Mark Driver
Benefit Rating: Transformational
Market Penetration: 5% to 20% of target audience
Maturity: Emerging
Definition:
AI-native software engineering includes practices and principles optimized for using AI-native tools across the software development life cycle to accelerate software delivery. AI-native practices go beyond human augmentation and involve using AI agents for asynchronously and autonomously executing long-running tasks that span multiple use cases and diverse roles. AI-native ways of working can deliver both productivity improvements and a creativity boost.
Why This Is Important
AI-native software engineering practices enable teams to focus on meaningful work that requires critical thinking, creativity, and user empathy, rather than spending time on repetitive tasks. By adopting AI-native methods beyond coding tasks, software engineering leaders can maximize the impact of AI in the software development life cycle (SDLC) and realize greater return on their technology investments.
Business Impact
AI-native software engineering leads to maximizing the use of AI across the SDLC. The 2025 Gartner AI in Software Engineering Survey shows a striking contrast between teams maximizing AI use across the SDLC versus those minimally using it for fewer use cases. For example, 55% of respondents who use AI for 10 or more use cases see an increased rate of innovation while 53% cite an increase in user/customer satisfaction, and 61% report an increase in developer job satisfaction.
Drivers
The primary value drivers for AI-native software engineering include:
- Need to go beyond productivity gains and use AI to drive innovation: As AI commoditizes code generation, the primary measure of engineering effectiveness is shifting from productivity to creativity and innovation. Used effectively, AI transforms the experience of people in upstream planning phases by serving as an ideation partner for roles such as product owners and user experience designers, enabling them to convert text prompts or visual sketches into prototypes and supporting better and faster decisions.
- Emerging practices, such as spec-driven development and context engineering: Spec-driven development combined with agentic coding tools that have access to better quality context help software engineering teams get closer to the aspiration of implementing a zero-friction SDLC. AI agents use specs to guide planning and implementation, enabling multiple asynchronous workstreams to run in parallel and deliver faster cycle times.
- Compounding the effects of AI-native development tools used in ensemble: AI-native development tools used in ensemble across the SDLC enable organizations to not only improve delivery speed but also build in quality guardrails. For example, AI code review tools, AI testing tools, AI code security assistants, and AI site reliability engineering tools continuously detect and remediate quality issues and incidents.
- Need to elevate the human experience (for example, developer experience): AI tools can significantly enhance human experience by reducing cognitive load and facilitating “flow state.” By automating tedious tasks (such as writing unit tests or migration scripts) and minimizing context switching and information retrieval (such as “explain this error” or “find this dependency”), AI allows engineers to minimize distractions.
Obstacles
- Blind trust in AI output: AI-native approaches create a new burden on developers and knowledge workers in general. Developers increasingly offload tasks to AI tools, which carry inherent risks of nondeterminism and hallucinations. Therefore, blindly trusting AI output without verification and explainability can potentially pose serious business risks, including reputational damage.
- Increased security risk: AI tools expand the threat surface via MCP servers, agent skills, agent plug-ins, and IDE extensions, which increases the potential for unforeseen vulnerabilities and security breaches.
- Developer burnout due to high-intensity work: While AI can free up time for creative work, there is a high risk that it actually intensifies work by drastically increasing baseline productivity expectations. Developers using AI-native techniques are more likely to experience increased cognitive load as they constantly validate AI output and take accountability for work they have not personally done.
User Recommendations
Adopt AI-native software engineering in three phases:
- Phase 1: Resolve constraints by mapping the software delivery value stream. Identify systemic bottlenecks and resolve them by judiciously using AI where appropriate. Discover pain points and improve the experience for all roles, not just developers.
- Phase 2: Reimagine the SDLC with asynchronous workflows. Parallelize tasks using asynchronous agentic workflows. Transform software delivery workflows — identify what steps can be eliminated and what stays the same. Enhance IDP capabilities to govern, monitor and control AI software engineering agents.
- Phase 3: Realize zero-friction SDLC with autonomous software delivery. Implement autonomous self-correcting and self-improvement loops and address pitfalls by expanding platform support for autonomous delivery and operations. Implement appropriate human oversight for autonomous workflows based on business criticality, acceptable risk, and architectural complexity.
Sample Vendors
Amazon Web Services; Anthropic; Cognition; Cursor; GitHub; GitLab; Google; Harness; Lovable; OpenAI
Gartner Recommended Reading
AI Code Security Assistants
Analysis By: Mark Horvath
Benefit Rating: Transformational
Market Penetration: 20% to 50% of target audience
Maturity: Early mainstream
Definition:
Artificial intelligence (AI) code security assistants (ACSAs) are technologies that help developers identify and remediate security vulnerabilities in code. They offer autoremediation suggestions and direct code assistance or chatbots, using forms of AI, such as generative AI (GenAI). ACSAs are primarily delivered as features of application security testing (AST) products and use cloud services to analyze code and make recommendations.
Why This Is Important
Developers tend to not identify and resolve security issues in their code. However, secure code training is recommended for application security programs, and AI code assistants can be a multiplier for learning. When properly trained, the large language models (LLMs) offered by AST vendors deliver more secure code. Developers write more secure code when they get effective answers in a security context and LLMs and ACSAs offer more scalable, security-centric code advice.
Business Impact
- ACSAs go beyond more general AI coding assistants by offering just-in-time (JIT) solutions to the specific security problems found by AST tools.
- Unlike most tools, ACSAs may be in a unique position to optimize several variables (e.g., security and code quality) at the same time.
- ACSAs are next-generation tools for closing one of the remaining gaps: JIT training and security remediation in shifting security left to improve product delivery time.
Drivers
- AI assistants, such as Claude, Gemini and Cursor, are becoming increasingly popular with developers. AI assistants are delivering useful results in multiple areas of their code, including secure coding and in the infrastructure and operations of the production environment.
- Shift-left initiatives — moving work from the runtime environment (the right) to the developer (left) — are incomplete solutions for code security. This is because the channels needed to supply developers with solid security guidance are limited and fragile. Initiatives often rely on human experts to guide the organization. ACSAs offer an opportunity to add virtual experts at many layers of the organization in a way that is easily consumed by developers.
- AST vendors, which have traditionally supplied tools for AppSec, have offered security code assistance for more than a decade, and have access to the core security coding data their tools generate. Using this data as a training corpus, and combining it with foundational models into ACSAs, was a logical next step.
- Developers believe that ACSAs will provide reliable security advice. The 2025 Gartner Software Engineering Survey (n = 300) found that a surprising 69% of developers expressed high or medium confidence in the tools.
Obstacles
- Most organizations worry about exfiltrating private data or intellectual property (IP) through AI assistants. There are ways to protect against this, but trust is low.
- GenAI occasionally hallucinates, identifying problems that are not real or are wrong, or giving explanations that sound plausible but are unsecure or unwise to use. This can be hard to detect, especially for junior developers.
- Code ownership issues are a concern, especially if an ACSA has contributed a significant amount of code. Given that the assistants are generally using code they were trained on, rather than creating original code, accidentally acquiring another organization’s IP is a concern.
- ACSAs are an example of optimizers, which have failed in the past by overcompensating for security while ignoring issues such as performance, reliability and code quality.
- AI token usage is currently heavily discounted. If that shifts to a full-cost model, that could seriously impact development budgets.
User Recommendations
- Continue to use traditional AST tools — static AST (SAST) or SCA — to measure security and code quality issues when adding an ACSA. Although it’s common to see an immediate increase in security metrics (e.g., code quality), watch the other indicators of code quality.
- Protect your privacy and IP by avoiding vendors that do not handle privacy and confidentiality issues with your code in a manner consistent with your organization’s policies and regulatory requirements.
- Retain and adjust existing methods of improving code security, as ACSAs become a bigger part of the developer experience.
- Continue programs such as security coaches and code reviews so they act as a balance to ensure that the advice developers receive is correct and helpful.
Sample Vendors
Black Duck; Checkmarx; GitHub; GitLab; HCLTech; OpenText (Fortify); Qwiet AI; Snyk; Symbiotic Security; Veracode
Gartner Recommended Reading
At the Peak
Agentic AI Governance
Analysis By: Svetlana Sicular
Benefit Rating: High
Market Penetration: Less than 1% of target audience
Maturity: Embryonic
Definition:
Agentic AI governance is the framework of policies, decision rights, guardrails, and oversight mechanisms for agents and agentic workflows. It ensures agents operate within defined constraints regarding safety, accountability, interoperability, and behavior. Agentic AI governance extends AI governance to address specific ethics, security, and business risks in multiagent orchestration, autonomous decision making, and agent-human dynamics.
Why This Is Important
As agentic AI moves to the core of the business and scales, governance is necessary to ensure the following:
- Accountability and guardrails for autonomous insights, decisions and actions.
- Interoperability, reliability and evaluation in dynamic environments.
- Conduct, coordination and compliance of agentic systems in heterogeneous environments.
- Compounded risks due to complexity in orchestration and interaction among components.
Business Impact
Successful agentic AI governance builds the trust and reliability essential for scaling autonomous agents and complex workflows. It reduces regulatory compliance costs — potentially by 70% by 2028 — allowing investment to shift toward strategic growth. It mitigates high-stakes risks such as collusion, insider threat, hallucinations, unethical behavior, and privacy violations. It provides the necessary framework to manage liability and ensure interoperability across heterogeneous environments.
Drivers
- Human accountability for agentic actions. Accountability mechanisms require explicit definition of roles, responsibilities and objectives for all stakeholders involved in agentic AI. Ownership and accountability for agentic decisions, actions and components require a multifaceted approach that spans policy, technology, and full awareness of organizational accountability.
- Agentic AI guardrails to manage complex risks must be integrated into the very design and function of the agent. The drivers for guardrails include the following unique agentic characteristics: goal-orientation and orchestrated collaboration; autonomy; perception and environmental interaction; reasoning and planning; tool veering and use; learning and behavior adaptation; memory to store and recall past scenarios and actions.
- Interoperability, reliability and evaluation in dynamic agentic environments. AI agents pop up in various departments that use disparate, rapidly changing and evolving frameworks from different providers. Governance precepts for a common technical stack help to reuse agents and make them reliable and trustworthy.
- Compounded risks due to complexity in orchestration and interaction stem from the interactions between probabilistic components, where a single error, such as an incorrect decision or parameter extraction, can trigger a catastrophic chain reaction. Plan for governance to evolve when agentic systems move from fixed workflows to more dynamic coordination and planning.
- Conduct, coordination, compliance and collusion of agentic systems. In complex environments, agentic AI can exhibit emergent, hard-to-predict behaviors created by hallucinations, bugs or infinite loops. When interacting with tools and data, it is difficult to ensure that agentic actions consistently align with human preferences. Autonomous agents handling sensitive data and executing tasks across various systems need to be aware of regulations, privacy and ethics.
Obstacles
- Governance could be perceived as a barrier to agentic AI adoption that is currently accelerating in the enterprises: Governance must support the agentic AI progress and focus on the immediate tasks at hand, rather than building out for potential future roadmaps.
- Decision making in dynamic, open-ended environments is hard to scale, reproduce, observe and monitor. It is aggravated by “decision amnesia,” where an organization lacks systematic tracking of decision outcomes. Decision intelligence is often undertaken backward: based on agentic hype rather than business objectives.
- Divergent approaches between AI tool providers and the identity and access management (IAM) industry create control challenges. AI tools often rely on basic authentication and authorization methods that result in fragmented security policies and complexity, which hinder visibility, accountability and compliance. Organizations are also struggling with agents that have their own credentials and API keys.
User Recommendations
- Extend AI governance to agentic AI: establish a framework that spans all agentic artifacts for accountable decision making and visibility for agentic operations.
- Promulgate a code of conduct for AI agents to establish ground rules for consistency with existing policies and values.
- Address interoperability, reliability and evaluation early, so that the organization makes a concerted and safe progress with agentic AI. Issue standards to enable reusability and sharing. Make a rule to define goals and success criteria for each agent, and further reflect them in evaluations and monitoring from the outset.
- Adopt solutions to observe, monitor and manage AI agents to streamline the development and optimization of agents.
- Establish human-in-the-loop escalation triggers and decision-centric practices, such as decision modeling, decision monitoring and decision risk assessments.
- Define access policies for agentic access to resources, monitoring their activities and conducting regular audits.
Gartner Recommended Reading
DevOps Continuous Compliance Automation
Analysis By: Daniel Betts, Chris Saunderson
Benefit Rating: Moderate
Market Penetration: 5% to 20% of target audience
Maturity: Adolescent
Definition:
As organizations implement or scale DevOps initiatives, they frequently struggle to effectively establish, measure, enhance, and evidence compliance requirements. Heads of I&O must leverage compliance automation tools to enforce policy guardrails, address gaps in compliance frameworks, and systematically audit security and compliance policies throughout the SDLC to demonstrate continuous and measurable improvement in their compliance posture.
Why This Is Important
DevOps organizations must align with a surging volume of regulatory requirements that are evolving at differing rates, and they will continue to do so as more compliance requirements are introduced. These requirements are expanding beyond the traditional areas of finance, health privacy, and personal privacy to include cybersecurity and contractual mandates plus government regulations.
Business Impact
DevOps continuous compliance automation (DCCA) tools help organizations achieve, sustain, and report on compliance as part of delivery pipelines and platforms. Enhance audit-readiness by automating the enforcement and assessment of compliance policies across application and infrastructure workflows. DCCA tools reduce the risk of compliance violations, which can result in fines, penalties, and reputational damage, and identify compliance gaps and security vulnerabilities early in development.
Drivers
- As organizations face an increasing number of regulatory obligations and more stringent reporting and enforcement, automating compliance will become even more valuable in maximizing flow and managing cognitive load.
- Regulatory compliance requirements and contractual obligations are growing and evolving. The expectation is that they must be supported with limited delay, while minimizing the impacts to the flow of customer value.
- The pressure to deliver software faster and more frequently has accelerated development cycles. Traditional, manual compliance processes can’t keep pace with this speed, making automation essential.
- Compliance activities are increasingly executed through automated testing for developer efficiencies, change management, segregation of duties, and access controls.
- Multiple DevOps toolchains often require compliance insights and must be under compliance control.
- Integrating DevOps workflows into GRC platforms is necessary to ensure visibility into compliance levels. As cloud-native application architectures and development models become more pervasive, integrating compliance into the toolchain will become more expected.
- Traditional compliance reporting, benchmarking, assessments, and remediation are increasingly too slow to support the needs of high-velocity digital business processes.
Obstacles
- Failure to engage with governance, risk, and compliance (GRC) subject matter experts early in the development life cycle leads to problems such as poor understanding of policies and ineffective implementation.
- DCCA tools require a formal change-controlled, secure DevOps toolchain to enable effective auditing.
- A lack of rule-set understanding and consistent implementation can impede DCCA tool adoption. Failure to consistently involve organizational compliance teams in implementation leads to a failure in delivering maximum value.
- Poorly implemented DCCA presents a business risk. If it is assumed that by implementing DCCA, delivered software becomes compliant without additional effort, organizations will face increased risk of compliance failure.
- DCCA tools can generate false positives (flagging issues that aren’t actually problems) or false negatives (failing to detect real issues). Managing these inaccuracies requires careful tuning and validation.
User Recommendations
- Collaborate on design, implementation, and an ongoing risk-based strategy to filter and prioritize with key stakeholders, including with internal GRC.
- Optimize work, taking into account compliance requirements, don’t bolt them on afterward, which reduces effectiveness, efficiency, and increases costs.
- Ensure compliance controls and evidentiary data are understood and applied earlier in the development process.
- Implement an augmented continuous approach to prevent, detect, and correct audit findings, removing manual reporting activities.
- Evaluate vendor solutions using GenAI and agentic AI to enhance compliance automation for automated policy generation, continuous monitoring, or code remediation.
- Enable continuous measurement by deploying efficient policy checking to measure benchmarks, perform assessments, and manage the mitigation of findings in real-time.
- Choose tools that integrate with your existing pipelines, GRC systems, security tools, and other relevant systems.
Sample Vendors
Anecdotes; CloudBees; Cytex; Drata; Hyperproof; Kosli; letsbloom; RegScale; Sprinto
Gartner Recommended Reading
MCP Cybersecurity
Analysis By: Craig Lawson
Benefit Rating: High
Market Penetration: 5% to 20% of target audience
Maturity: Emerging
Definition:
Model Context Protocol (MCP) is a new open protocol standardizing how AI apps and agents connect to existing resources. MCP cybersecurity is the process of applying architectural principles to ensure the secure usage of MCP by preventing misuse of AI-agent connections to tools, data and MCP servers. It addresses identity, authorization, data, monitoring and governance risks introduced when autonomous or semi-autonomous AI agents invoke capabilities enabled via MCP.
Why This Is Important
Driven by the push for AI agents, MCP is an emerging open standard that replaces hard-coded APIs to act as a universal integration method to a wide range of services and data. Backed by major AI solutions and an increasingly large number of SaaS applications and even cybersecurity solutions, its enterprise impact will likely have a similar impact to that of HTTP. However, rapid shadow adoption that can be hosted from the cloud to local hosts creates a new attack surface. Securing MCP is a key concern for cybersecurity teams to prevent novel vulnerabilities and other styles of exploitation like tool poisoning and rogue agent behavior.
Business Impact
Securing the MCP is a critical cybersecurity issue for any organization developing or using AI-enabled enterprise applications. MCP provides a simplified integration layer for high-speed AI automation, enabling models to interact with real-time enterprise systems. However, a lack of adequate visibility, data security, threat protection, and governance exposes businesses to significant risks, including legal liability, supply chain compromise, and severe, high-profile breaches that can impact users, data, and numerous other business functions.
Drivers
- The push for AI: Organizations looking to deliver innovation and not get caught in the hype require AI agents that can access enterprise data, in its existing format, and perform a wide range of actions.
- Widespread ecosystem adoption: Major AI and technology leaders, including Anthropic, OpenAI, and Google DeepMind, have adopted or integrated MCP, cementing it as the foundational protocol for AI agent tool calling and general interoperability support.
- Accelerated SaaS integration: Vendors across all enterprise software categories, including some cybersecurity vendors, are rapidly embedding MCP to easily add AI-driven capabilities to their platforms, driving an explosion of vendor-hosted MCP servers that require governance.
- The proliferation of shadow AI agents: Teams are adopting agentic AI and running local MCP implementations faster than cybersecurity teams can track them, creating an invisible attack surface that demands centralized management and visibility.
- The need for model agility: MCP offers organizations the ability to switch out or between resources used by agentic AI as new versions are released or providers change, avoiding the technical debt of hard-coded API integrations.
- Inherently insecure design: MCP was built for interoperability and ease of use originally and its security features are still evolving; they are not inbuilt by default, but the details of the implementation are critical.
Obstacles
- Opaque vendor environments: Consuming third-party MCP instances introduces trust concerns, data security and sovereignty issues as vendor-hosted servers may lack adequate access controls, sandboxing, and logging capabilities. Untrusted MCP clients and servers can also have malicious intent.
- Native model support for other existing methods: MCP interest drops as models handle other protocols more easily and tool providers shift to skill.md.
- Evolving protocol maturity: The standard is updating rapidly, creating a risk of accumulating technical debt and orphaned, unpatched deployments if organizations fail to budget for ongoing support, monitoring and updates.
- Novel AI-specific vulnerabilities: MCP facilitates complex attacks like indirect prompt injection, tool poisoning, and rogue agent behavior, where AI tokens can generate valid-looking traffic with malicious intent.
User Recommendations
- Treat all MCP deployments as privileged assets by enforcing transport security (TLS 1.3), using OAuth for agent authentication, and segmenting roles with scoped, short-lived tokens.
- Deploy runtime controls such as AI/MCP gateways and proxies to mediate external traffic, enforce zero-trust policies, and continuously monitor anomalous agent behavior.
- Use SSE and other endpoint/server controls to enable discovery of MCP servers and clients and as MCP usage within your SaaS/cloud estate. Other network security methods, like NDR, can also help identify MCP usage.
- Monitor for MCP usage within business-critical SaaS applications.
- Cybersecurity projects like OWASP also have a set of pragmatic recommendations worth adopting for MCP (see OWASP MCP Top 10).
- Demand transparency from vendors regarding their MCP cybersecurity posture, requiring evidence of input validation, sandboxing, and data loss prevention before consumption.
- Document and describe MCP use cases in relation to data and other processes and document and maintain ownership “chain of custody” for your organization.
- Develop tailored incident response playbooks for MCP-specific failures, including tabletop exercises simulating prompt injection, credential theft, data loss and unauthorized tool access.
Gartner Recommended Reading
Sliding into the Trough
Rust
Analysis By: Manjunath Bhat
Benefit Rating: High
Market Penetration: 5% to 20% of target audience
Maturity: Adolescent
Definition:
Rust is a modern systems programming language designed for memory safety, speed and concurrency with the benefit of being energy-efficient. The language has built-in constructs that enable robust memory management without the need for garbage collection, improving both speed and security at runtime. However, the same constructs make the language harder to learn. The Rust Foundation, a nonprofit organization, manages its development and fosters an open-source ecosystem of supporting toolchains.
Why This Is Important
Unlike established languages such as C and C++, Rust includes built-in support for compile-time memory-safety checks and shared-state concurrency for thread safety. These benefits, plus no need for a Java-style garbage collector, make Rust uniquely suited for building system software with stringent security, safety and reliability requirements. Airtable, a product road-mapping provider, rewrote its database from TypeScript to Rust. Moreover, Rust also works well for developing firmware, device drivers, game engines, audio and video codecs and developer tools. For example, OpenAI rewrote the Codex CLI, an AI coding agent, from TypeScript to Rust.
Business Impact
Malicious actors routinely exploit memory-related security weaknesses, the most disclosed software vulnerabilities. Both software vendors and its customers pay dearly to patch vulnerable software and deal with incident response and application downtime. Rust provides a memory-safe alternative. The Gartner Software Engineering Survey for 2025 shows Rust increasing by 8% but being used in a limited capacity (see Infographic: Adoption Trends of Top Programming Languages and Frameworks).
Drivers
- Software supply chain security mandates: The U.S. CISA, NSA, FBI, and international cybersecurity bodies launched the "Secure by Design" initiative, setting a January 2026 deadline for software manufacturers to publish memory-safety roadmaps.
- Memory safety: The White House Office of the National Cyber Director released a technical report calling for adoption of memory-safe programming languages such as Rust. Rust is specifically named as a memory-safe alternative to C/C++, both deemed memory-unsafe. However, no programming language, despite its built-in safeguards, can guarantee memory-safe programs. For example, Rust code contained within an unsafe block can still result in memory-related security defects.
- Rust Foundation and Safety-Critical Rust Consortium: The Rust Foundation created the Safety-Critical Rust Consortium, a subgroup that supports Rust use to build safety-critical software in verticals such as automotive, aerospace, healthcare and utilities.
- Operating system development: Rust is now used to build low-level system software. Operating systems have included Rust for kernel development. For example, the Linux kernel supports Rust as the only other programming language besides C and assembly. Microsoft prioritizes Rust in Windows development and is adding support for Rust for device-driver development. Android supports Rust as a memory-safe alternative to C/C++. Amazon, Google and Microsoft encourage their developers to choose Rust over C/C++ for building new functionality in their system software.
- WebAssembly: Because Rust can be compiled to WebAssembly, or Wasm, developers can write Rust code that safely runs within a browser sandbox. All major browsers support Wasm, which expands Rust component reach. In addition, WebAssembly provides a way for Rust to interoperate with other Wasm-compatible languages.
Obstacles
- Developers encounter a steep learning curve with Rust. The same features that make Rust an appealing alternative to memory-unsafe languages also present developers with new programming constructs and paradigms. Without a thorough understanding of the memory ownership model, developers can accidentally introduce defects, negating the language’s benefits.
- The industry, including open-source and commercial software, is unlikely to either rewrite or provide Rust alternatives to existing libraries and developer tooling that are written in C, C++ and Java. This creates an interoperability challenge with underlying system dependencies across libraries, components and toolchains. As a corollary, increased developer friction from immature, nonexistent or unproven DevOps tooling can hurt developer productivity and the developer experience.
- Technical difficulties and collaboration issues beset Rust support in the Linux kernel. Debate over using Rust for device drivers in Linux splits the community into two camps: those who support the language and those who oppose a multilanguage codebase.
- Backward compatibility between Rust versions has been a challenge. For example, Rust 1.82 enabled a Wasm feature by default for WebAssembly System Interface builds that was a breaking change from Rust 1.81.
User Recommendations
- Make a business case for a memory-safe roadmap for software and firmware assets that require repeated memory-related security patches. Include Rust as a memory-safe programming language.
- Evaluate Rust for new system software development. Determine whether vulnerability risk from memory-safety bugs outweighs the cost of upskilling, modernizing the technology stack and adopting a more complex technology stack with a small ecosystem of developers, frameworks and tools.
- Upskill programmers by providing access to Rust-specific training programs, fostering a Rust community of practice and incentivizing developers to participate in and contribute to the Rust ecosystem. Include Rust skills in developer job requisitions for building system software.
- Ease the adoption of Rust by working with platform engineering teams to support tools for improved developer experience and productivity.
- Avoid mass modernization efforts to rewrite existing software in Rust. Understand that porting from one language to another not only can exacerbate functional issues but also may introduce security issues because of poor understanding of the language constructs.
- Prefer Rust over memory-unsafe languages for programming new system software (e.g., embedded software, Wasm applications and automotive electronic systems).
- Avoid Rust in existing business applications written in other memory-safe languages, including Java, C# and Go. The risk of business disruption from interoperability issues and lack of developer expertise outweighs the benefits of memory safety and high performance.
Sample Vendors
AdaCore; Dioxus Labs; Ferrous Systems; HighTec EDV Systeme GmbH; JetBrains; OxidOS Automotive; Veecle
Gartner Recommended Reading
Agentic Cloud Development Environments
Analysis By: Manjunath Bhat
Benefit Rating: High
Market Penetration: 5% to 20% of target audience
Maturity: Adolescent
Definition:
Agentic cloud development environments (CDEs) offer a secure and governed approach to software development, providing either a cloud-hosted or self-hosted workspace equipped with agentic coding tools. These sandboxed, isolated environments separate the development workspace from physical endpoints, which simplifies administration and reduces the risk of running AI-generated untrusted code. In an agentic CDE, both human engineers and AI agents work together on code artifacts.
Why This Is Important
As AI coding agents advance from completing function snippets to developing complete functionalities, local development environments become a liability due to compute constraints, security risks (like privilege escalation), and the difficulty in maintaining consistency and reproducibility. Agentic CDEs resolve these issues by offering a secure, automated workspace that is optimized to meet the computational and experiential needs of humans and software engineering agents.
Business Impact
Regulated organizations such as banks and government agencies stand to gain the most. These organizations can meet regulatory and security obligations by protecting intellectual property and securing sensitive data. Organizations building AI applications can use agentic CDEs to benefit from hosted GPUs for faster training and inference. Software engineering leaders benefit from faster onboarding with new hires gaining same-day access to a consistently reproducible development environment.
Drivers
- AI-native software engineering: CDEs are increasingly used as a distribution channel for developers to adopt approved agentic developer tooling, such as AI coding and augmented testing agents. This drives the adoption of agentic CDEs while simultaneously minimizing the security and compliance risks associated with using unvetted AI tools within the organization.
- Mitigating software supply chain security risks: Security teams gain centralized control to manage, govern and secure development environments, significantly reducing the threat of supply chain attacks. This includes the ability to implement zero-trust access policies for source code and the delivery pipeline. Furthermore, because CDEs are defined by code, development tools and dependencies can be kept consistent.
- Improving developer experience: The complexity and unreliability associated with maintaining and configuring local machines, due to numerous plug-ins, MCP and API integrations, is drastically reduced. Agentic CDEs provide seamless integration with Git repositories and continuous integration/continuous delivery (CI/CD) tools.
- Reducing configuration drift: Developing and testing modern, complex applications such as mesh services, event-driven apps and container-native applications is challenging on local machines. Agentic CDEs make it easier for developers to ensure consistency of development environments.
- Protecting intellectual property (IP) in outsourcing: Organizations increasingly use CDEs as a primary option to secure their IP when outsourcing software development. Gartner client inquiries indicate IP protection and risk mitigation as the primary demand drivers for CDEs among regulated companies.
Obstacles
- Agentic CDEs introduce additional costs on top of existing DevOps tooling expenses. These increased costs can be excessive, particularly for development teams that currently leverage open-source tools for application development and delivery on local systems.
- Agentic CDEs must evolve to keep pace with innovations in the agentic AI technology landscape. For example, IT administrators will require these tools to provide AI cost transparency and enforce necessary guardrails.
- Security and compliance policies may prohibit using the public cloud for development, which could rule out agentic CDEs that depend on public cloud services. It is important to note, however, that CDEs can be provisioned in self-hosted environments such as a private data center.
- Developers may resist CDEs because it could hinder their capacity for experimentation and rapid innovation due to restrictive IT governance policies.
User Recommendations
To effectively integrate agentic CDEs into development workflows, software engineering leaders should:
- Prioritize sandboxing and isolation capabilities to prevent misbehaving or compromised agents from accessing sensitive data, restricted network segments, or local servers and endpoints. Enforce privilege access management controls and network policies to minimize the risk of data exfiltration.
- Implement AI governance and security controls to reduce shadow AI risks and compliance gaps. Deploy an AI gateway to mediate traffic between the CDE and model providers, and consolidate API keys, create audit logs and provide visibility for token consumption. Integrate CDEs with enterprise secret managers (like HashiCorp Vault) to ensure agents can access necessary credentials.
- Take a platform engineering approach to defining development environments as code — tools, libraries and configurations to support the applications being built and underlying technology stacks.
Sample Vendors
Anysphere (Cursor); Citrix; Coder; Daytona; Docker; E2B; Harness; Microsoft; Ona; Together AI
Gartner Recommended Reading
Application Security Posture Management
Analysis By: Jason Gross
Benefit Rating: High
Market Penetration: 20% to 50% of target audience
Maturity: Early mainstream
Definition:
Application security posture management (ASPM) platforms centralize the visibility and governance of application security-related risk. They ingest, deduplicate and normalize signals from security tools across DevSecOps pipelines and runtime environments, enriching them with the business and operational context for accurate risk measurement and remediation priorities. ASPM serves as an application security program control plane, providing policy enforcement automation and workflow orchestration.
Why This Is Important
Disparate security tools generate fragmented signals when scanning and testing applications within pipelines and environments across the software development life cycle (SDLC), making risk visibility and governance challenging. ASPM unifies and normalizes findings from diverse tools, enabling centralized oversight and policy enforcement. This empowers organizations to prioritize and remediate the most critical risks efficiently, aligning security efforts with business objectives.
Business Impact
ASPM streamlines application risk management by consolidating and correlating security findings, reducing noise, and enabling accurate risk measurement and actionable remediation. Teams benefit from improved productivity, reduced alert fatigue and enhanced collaboration. The result is accelerated risk reduction, stronger compliance and increased confidence in application security posture.
Drivers
- Application security tool sprawl: Organizations run many security tools to surface potential risk across multiple risk domains (e.g., first-party code, dependencies, containers) throughout the SDLC and DevSecOps pipelines. This results in a fragmented view of risk, hindering aggregate risk reporting and requiring “swivel chair” operations from both application security and software engineering teams.
- AI-driven development: The adoption and use of AI coding assistants to accelerate development increases the volume of new and changed code, which amplifies the volume of signals produced from disparate security tools.
- Inaccurate risk measurement: Disparate security testing tools often produce duplicate or overlapping findings, inflating perceived risk and undermining the credibility of application security programs. Inconsistent and inaccurate reporting erodes trust with senior leadership and makes it difficult to secure ongoing support for application security initiatives.
- Ineffective risk prioritization: Individual testing tools and methods (e.g., SAST, DAST) used to identify potential risk often lack the business context, operational telemetry and threat intelligence needed to accurately assess the likelihood and impact of exploitable security flaws. This results in misaligned remediation priorities that misdirect engineering capacity away from the resolution of critical issues presenting the greatest organizational risk.
- Poor developer experience: Application security processes are not aligned with developer workflows, creating friction, reducing adoption and limiting the effectiveness of remediation efforts.
- Inconsistent policy enforcement: Security policies, risk thresholds and remediation expectations are applied inconsistently across disparate tools and teams, limiting the organization’s ability to enforce standards, demonstrate compliance and manage risk at scale.
Obstacles
- Integration complexity: Integrating ASPM platforms with a diverse set of existing security tools, DevSecOps pipelines and cloud environments can require significant customization and ongoing maintenance, especially in large organizations or those using legacy tools.
- Data quality and normalization challenges: Findings ingested from disparate tools may be incomplete, inconsistent or lack sufficient context, which complicates effective deduplication, correlation and normalization of security signals.
- Immature application security processes: Organizations without a clear operating model for application security, shared accountability or established, cross-functional workflows often struggle to implement and operationalize ASPM solutions effectively.
- Cost and justification: The perceived or actual cost of ASPM platforms, including licensing, integration and ongoing management, can be a barrier to adoption, especially when the return on risk reduction or investment is not clearly articulated.
User Recommendations
- Prioritize ASPM adoption if your organization operates multiple development teams, has diverse SDLC processes or has a broad mix of security tools.
- Evaluate how well ASPM solutions integrate with your existing toolchain and their ability to ingest, normalize and correlate data at the scale and complexity your environment demands.
- Identify and engage key stakeholders from security, development, product management and operations to ensure buy-in, clarify requirements and prioritize opportunities for cross-functional workflow integration.
- Define goals and success metrics for risk reduction, process improvement and reporting prior to tool selection and implementation to align on how the value of ASPM will be measured and to secure ongoing executive support.
- Develop in-house ASPM capabilities when organizational scale, integration complexity and requirements exceed commercial offerings, provided internal engineering capabilities and bandwidth can sustain those capabilities as a long-term product.
Sample Vendors
Apiiro; ArmorCode; BoostSecurity; Cycode; Invicti; Jit; Legit Security; OX Security; Phoenix Security; Seemplicity
Gartner Recommended Reading
AI-Augmented Testing
Analysis By: Joachim Herschmann
Benefit Rating: High
Market Penetration: 5% to 20% of target audience
Maturity: Adolescent
Definition:
AI-augmented testing is the use of AI and agents for continuous, self-optimizing and highly autonomous testing in the software development life cycle (SDLC) with the goal of making testing independent from human intervention. It extends traditional test automation beyond the automated execution of test cases to include automated planning, creation, maintenance and analysis of tests and test prioritization, test analysis and test value scoring.
Why This Is Important
Software engineering leaders are looking for more efficient ways of accelerating testing to quickly evaluate a system’s functionality, ensure it meets business needs and satisfies functional and nonfunctional requirements. AI-augmented testing addresses this need and enables highly autonomous testing that frees engineering teams from tedious manual testing and creating and maintaining brittle test automation.
Business Impact
The adoption of AI-augmented testing has the potential to democratize testing, reduce costs and improve an IT organization’s ability to serve and delight its customers. It can enable the fine-tuning of scenarios for testing as part of a continuous quality strategy aimed at optimizing the end-user experience. It will also help to build a closed-loop system that quickly provides continuous feedback about critical quality indicators and helps to reduce the costs of creating and maintaining tests.
Drivers
- A high dependency on human expertise and interaction limits how quickly modern digital businesses can design, build and test new software.
- Where automated testing is already in place, current levels of automation often remain below expectations due to a continued dependency on human intervention to maintain the automation as applications under test (AUT) evolve.
- The pressure to innovate quickly for market differentiation without compromising on quality relies on both an increased velocity and a higher degree of autonomy of the related activities.
- Product teams struggle to deal with the increasing complexity of applications, leading to increased cognitive overload. Complex architectures increasingly require an understanding of many elements including cloud-native architecture, microservices and multiple front ends and AI-powered services.
- Increased adoption of AI and agentic development not only results in a faster development and delivery cadence, but also comes with a dramatically rising need for more testing.
- Businesses want to reduce test operation and maintenance costs associated with traditional tools and open-source software (OSS) solutions.
- Compliance regulations, such as General Data Protection Regulation (GDPR) for data privacy and Web Content Accessibility Guidelines (WCAG) 2.1 Level AA for accessibility, are enhanced by AI-augmented testing.
Obstacles
- Currently available AI-powered tools are evolving fast, and specifically, agentic testing solutions still need to prove their value when used at scale. Multiple challenges exist. For example, generated tests may be of limited value because the goal given is to make them pass, which may lead to the generation of trivial tests that are more likely to pass.
- Risks, common to GenAI, are exacerbated when AI agents gain agency and handle more complex operations autonomously and with limited oversight and governance. Left unchecked, agents can execute processes that compromise the system, violate regulations or expose data to unauthorized parties.
- Underestimating the time required to acquire new skills and setting wrong expectations about the time required to become successful can be obstacles. Roles will evolve, with QA professionals becoming the supervisors and orchestrators of the testing process with the implementation of automated tests and their execution being given to agents.
User Recommendations
- Set the right expectations about the potential and limitations of AI-augmented testing and ensure that humans are always in the loop to verify the results produced by AI-augmented testing tools. This is particularly relevant for tools employing GenAI to automatically create tests, as generated tests may be completely useless or result in false positives or negatives.
- Start evaluating AI-augmented testing tools now to understand the current possibilities and limitations of these products. Build a roadmap to solve the development organization’s most pressing quality challenges.
- Increase and communicate the value of AI-augmented testing tools by exploring additional use cases beyond core test automation scenarios, which limit automation primarily on the execution of tests. For example, look for shift-left scenarios, such as generating test scenarios from requirements or from user stories and contextual information contained within the codebase (including code and documentation).
Sample Vendors
Applitools; Katalon; Keysight; OpenText; Parasoft; Perforce; SmartBear; Tricentis; UiPath
Gartner Recommended Reading
API Security Testing
Analysis By: Esraa ElTahawy, Giles Williams
Benefit Rating: High
Market Penetration: More than 50% of target audience
Maturity: Adolescent
Definition:
API security testing is a specialized type of application security testing (AST) that identifies vulnerabilities in APIs. Checks should include traditional application vulnerabilities (such as injection attacks) and API-specific issues (e.g., broken-object-level authorization). Discovery capabilities are sometimes supported to ensure that unknown APIs are identified and tested for vulnerabilities.
Why This Is Important
APIs represent a major attack surface for web-enabled applications. Attacks on and abuse of APIs result in serious adverse consequences, including data breaches and other security incidents. DevSecOps teams focus on the need for API security testing in development to prevent these consequences. Vulnerability assessment teams may test the security of production APIs.
Business Impact
APIs are a foundational element of many organizations’ digital transformation efforts. Hence, securing APIs from attack and misuse is an ongoing concern for many cybersecurity leaders. Pre- and postdeployment API-specific testing builds a solid foundation for an overall API security strategy.
Drivers
- API usage has become common in application architectures to enable information flow and support transactions between processes, applications and systems. API development is also increasing with the increased deployment of AI applications. However, this growth continues to attract the attention of attackers, and APIs have become the primary attack surface for many systems.
- API attacks have resulted in data breaches and other security incidents, inflicting significant damage to organizations and individuals. As a consequence, security leaders — along with the business leaders whose applications are supported by APIs — are increasingly interested in API security testing.
- API security testing helps avert the tangible and intangible costs associated with breaches and other types of security incidents.
- Traditional AST tools — static, dynamic and interactive — were not originally designed to test for some of the unique vulnerabilities associated with typical API attacks. Nor were they aimed at newer types of APIs, such as GraphQL or gRPC. API-specific vulnerabilities and modern API formats prompt security and development teams to implement specialized API security tools focused on testing and protection from threats, or a combination of the three.
Obstacles
- The effort to move past traditional tools that offer inconsistent support for detecting API-specific vulnerabilities can hinder adoption. APIs are susceptible to most traditional application attacks, but other attacks are also common, and specialized tools or penetration testing may be needed to reliably detect security flaws.
- Tools for testing may not support all API protocols. SOAP remains in widespread use, although REST APIs are supplanting it. GraphQL-based and gRPC-based APIs are increasingly common and require additional support from tool vendors for effective testing.
- Evaluation and selection efforts can be complicated because various types of vendors, including traditional AST vendors as well as API security testing and protection vendors, offer such capabilities.
- The number of API endpoints typically determines licensing and pricing, which can be difficult to budget for without proper discovery.
User Recommendations
- Begin tool evaluation by focusing on the criticality of APIs, their security and business risks, and the technical requirements they pose. This will help identify needed functions and the level of testing necessary.
- Assess the suitability of the existing testing and discovery capabilities that tools in your application security portfolio provide. Many testing tools now include support for APIs, but tests may focus primarily on traditional application vulnerabilities, not those specific to APIs. API security tool capabilities — including discovery, testing and threat protection — often overlap.
- Evaluate dedicated API security testing tools in your incumbent provider offerings. The tools may also offer additional options, including audit of design-stage API specifications, discovery, vulnerability scans and threat protection.
- Complement automated testing tools with penetration testing services for comprehensive coverage, because traditional AST is often unable to detect some common API-specific vulnerabilities.
Sample Vendors
Akto; APIsec; AppSentinels; Cequence; Equixly; Levo; SALT security; StackHawk; Traceable (by Harness); Wallarm
Gartner Recommended Reading
Threat Modeling Automation
Analysis By: William Dupre
Benefit Rating: High
Market Penetration: 20% to 50% of target audience
Maturity: Early mainstream
Definition:
Threat modeling automation tools help with the creation of security requirements and threat models. Such tools highlight potential security ramifications of application architectures and recommend secure coding practices or architectural mitigations. They also can manage threat libraries, track mitigations and integrate security analysis into the software development life cycle (SDLC).
Why This Is Important
Threat modeling is key to creating applications that are secure by design. Automated tools enhance the threat modeling process in the design phase by accelerating threat identification and improving consistency. Although they do not secure applications, automated tools help in the creation of secure application architectures and ensure identification of appropriate and specific security requirements.
Business Impact
Threat modeling automation tools significantly decrease the effort required to create and maintain threat models, security requirements and risk assessments. This ensures early definition of security requirements that are specific to individual projects while costs and risks are low, rather than later in the development process. This approach offers significant benefits to multiple groups within an organization, including architects, developers, security teams and even business stakeholders.
Drivers
- Organizations of all kinds continue to struggle to create secure applications. Issues include inadequate security capabilities, such as authentication, access control and data protection, and fundamental security design flaws, all of which leave applications vulnerable to attack.
- Secure-by-design initiatives and secure software compliance mandates make threat modeling an essential practice. Automated threat modeling tools make the practice faster and more scalable. They also help ensure that specific requirements associated with mandates and regulations are addressed.
- Modern applications — incorporating distributed cloud-native technologies, increased use of internal and third-party APIs, and agentic AI — are more complex and, as a result, prove difficult to manually and accurately model for threats. Threat modeling automation speeds the threat modeling process and helps modelers identify threats and relevant countermeasures.
- The rapid pace of development limits the time and resources available for threat modeling. Iterative approaches to development, such as agile practices, mean that threat models must be updated more frequently. Both factors strain manual approaches and increase the likelihood that threat modeling will be limited in scope or simply skipped entirely.
- Vendors are adding AI capabilities into threat modeling and other application security products to enable better automation and identification of threats in the software development process.
Obstacles
- The ability to accurately represent a rapidly changing application remains a weak spot of threat modeling automation tools. Most of today’s tools require user intervention to update models as applications change, which leads to abandonment. This is improving as vendors begin to link systems directly to cloud platforms or infrastructure-as-code files, ensuring that changes are reflected automatically in the model, which will then automatically produce updated guidance.
- Capabilities vary. Free and open-source tools enable easy adoption but fall short when modeling more complex systems.
- Most organizations still focus on application security testing as they establish an application security program. These tools are essential to identifying vulnerabilities in code during the development stage but fail to identify design flaws during planning.
User Recommendations
- Treat threat modeling and security requirement generation as primary practices within a secure SDLC. Threat modeling automation tools can help accelerate these tasks while incorporating threat and security requirement knowledge from tool vendors.
- Use these tools to automate manual or overlooked efforts. Doing this ensures that threat modeling and security requirement generation activities are incorporated into the development workflow. Test cases must then be created to ensure security requirements are effectively covered.
- Evaluate emerging AI-based capabilities that support threat modeling. AI offers the potential for improved analysis and efficiency, threat identification and for simplified interaction with the tools.
- Train development, engineering, operations and architectural staff in the use and value of threat modeling automation tools. Encourage their use early and continuously in the development process and after deployment to validate application threat protection efforts.
- Define success metrics and ROI upfront. Establish clear goals for threat identification, process improvement and reporting before implementation to align on value measurement and secure ongoing executive support.
Sample Vendors
Aristiun; SecureFlag; Security Compass; ThreatModeler; TrustOnCloud; Tutamantic Sec
Gartner Recommended Reading
Climbing the Slope
Software Supply Chain Security
Analysis By: Aaron Lord
Benefit Rating: Transformational
Market Penetration: 20% to 50% of target audience
Maturity: Early mainstream
Definition:
Software supply chain security (SSCS) protects software, developers and environments from compromised code, tools, identities and pipelines during development, delivery and postdeployment. SSCS reduces third-party risks through policy-based dependency curation, software composition analysis (SCA) and software bill of materials (SBOM) inspection. SSCS tools establish artifact provenance and traceability via signing and verification as artifacts move through development and delivery pipelines.
Why This Is Important
SSCS transcends organizational boundaries and includes external entities in addition to internal systems. Internal systems include software delivery pipelines, software dependencies and software development environments. External entities include commercial off-the-shelf software (COTS), open-source software (OSS), third-party AI components and system images. Organizations have greater control over internal systems and little to no control over external entities.
Business Impact
- Identifies and mitigates security and compliance risks associated with widespread third-party software use.
- Reduces developer friction and productivity loss caused by attacks on tools, environments, pipelines and infrastructure used for software development, delivery and runtime operations.
- Supports governance and regulatory requirements by making software delivery infrastructure auditable through automated enforcement of application security policies.
Drivers
- State-sponsored attacks: OSS is increasingly vulnerable to infiltration by nation-state threat actors. As a result, state-sponsored software supply chain attacks have grown more sophisticated and prevalent, affecting organizations across sectors worldwide. These attacks exploit vulnerabilities in software (for example, Codecov) or compromise the software development life cycle (SDLC), as seen in the SolarWinds and NotPetya incidents. SSCS plays a critical role in reducing these risks.
- Regulatory compliance and government mandates: Governments, policymakers and regulators worldwide mandate third-party supplier assessments, continuous vulnerability scanning and SBOMs to establish a trusted software supply chain. Examples of mandatory regulations include the Improving the Nation's Cybersecurity, EU Cyber Resilience Act, NIS2 Directive: securing network and information systems, and the Federal Food, Drug, and Cosmetic (FD&C) Act.
- Pervasive use of open source and reliance on third-party software: Most software applications rely on third-party code through open-source dependencies. Based on hundreds of analyst interactions, Gartner estimates that more than 95% of organizations use OSS, often without full awareness.
- Use of open-weight AI models: Easy access to open-weight large language models (LLMs) and low integration barriers introduce new software supply chain risks. The 2026 Gartner Software Engineering Survey shows that 43% of respondents rank building AI-powered features or applications among their top priorities. SSCS enables organizations to identify LLM usage, assess known model risks and enforce policies that prevent the use of unapproved models. These risks include weak model provenance, unsupported models and geopolitical restrictions on model use.
Obstacles
- Most organizations lack a full understanding of SSCS and have not adopted a comprehensive approach to software supply chain risk. Many focus on acquiring SBOMs but have not defined how to evaluate, store, or use them.
- Efforts to secure software artifact integrity and provenance across the supply chain are emerging but vary in scope, execution, and adoption. Policies for allowed dependencies often cause friction and require negotiation among software engineering, application security, and platform engineering teams.
- Adoption of capabilities that harden DevOps pipelines through artifact integrity validation and automated policy enforcement remains comparatively low. Historically poor developer experiences with signing and verification workflows in continuous integration/continuous delivery (CI/CD) pipelines slow adoption. Tool heterogeneity across DevOps pipelines further complicates artifact attestation creation and pipeline integrity assurance.
User Recommendations
- Identify and mitigate security and compliance risks associated with widespread third-party software use, including open-source and commercial software, third-party AI LLMs, Model Context Protocol (MCP) servers and containerized workloads.
- Reduce visibility gaps in the software supply chain by using SCA and SBOMs to manage third-party risk and ensure auditability and traceability across pipeline activities and interactions in the SDLC.
- Protect software integrity throughout the delivery process by signing and verifying build artifacts, establishing provenance data and preventing the use of noncompliant artifacts.
- Improve the security posture of the software delivery process by automating policy enforcement across the SDLC and detecting and resolving misconfiguration errors in DevOps tooling.
Sample Vendors
ActiveState; Apiiro; Arnica; BoostSecurity; Cycode; Endor Labs; GitHub; JFrog; Lineaje; OX Security
Gartner Recommended Reading
Zero-Trust Strategy
Analysis By: John Watts, Thomas Lintemuth
Benefit Rating: High
Market Penetration: More than 50% of target audience
Maturity: Mature mainstream
Definition:
Zero-trust strategy establishes program-level activities to implement zero-trust principles within an environment. It replaces implicit trust with explicit and adaptive trust aligned with a calculated risk of access to the sensitivity of the asset. CISOs typically execute a zero-trust strategy to achieve a risk-optimized security posture for their organizations.
Why This Is Important
Organizations need a framework to drive organizational objectives, such as reducing risk of ransomware. Risk is often increased when attackers abuse implicit trust in environments to achieve lateral movement, employ available exploits and gain privilege escalation. Zero-trust strategy limits the level of security controls to the resource sensitivity to improve end-user experience. Moreover, it matches an attacker’s ability to bypass static controls by establishing continuous trust assessments.
Business Impact
A zero-trust strategy establishes objectives based on cybersecurity principles to improve an organization’s end-user experience and reduce the risk of certain cybersecurity threats. As a result, traditional security approaches are evolving to use fine-grained, adaptive access controls. This limits the impact of incidents and enables the digital transformation of businesses by installing flexible security controls closer to the assets that need protection.
Drivers
- Hype about zero trust conceptually drives organizations to adopt a zero-trust strategy, resulting in high visibility across organizations.
- Government mandates and private-sector initiatives establish zero-trust strategies as a response to major security incidents, such as ransomware and data exfiltration. Attackers abuse exposures and excessive trust extended to user accounts, devices and workloads.
- A need to establish higher levels of trust for accounts, devices and workloads beyond location and proximity as a single, weak factor for trust.
- A desire to move from a “deny by exception” to a “deny by default” approach to limit access to an organization’s critical resources.
- A need to support broader digital transformation initiatives by placing trust decisions closer to the resource that needs protection, regardless of the execution or hosting environment.
Obstacles
- The hype from vendors around zero trust often overpromises their ability to achieve the vision of an organization’s zero-trust strategy.
- Poor communication by strategic leaders leaves the term “zero trust” unclear, leading to organizational resistance and the misinterpretation that the organization lacks trust in its employees.
- A lack of integration with other strategic initiatives across the organization slows adoption.
- The required involvement and availability from business domain stakeholders and technical staff limit the use of outsourced strategy development to overcome skills and resource constraints.
- External constraints, such as technical debt and integration of multiple technologies from different security vendors, limit the strategic scope and require more resources for implementation than organizations anticipate.
User Recommendations
- Make the zero-trust strategy part of a broader vision for cybersecurity integrated with other cybersecurity strategies, such as data, endpoint and application security.
- Establish an identity-first strategy and mature identity practices, as these are prerequisites for a zero-trust strategy.
- Collaborate with stakeholders from security and nonsecurity functions to avoid confusion about the term “zero trust.”
- Map the zero-trust strategy as a way to enable business initiatives, such as digital transformation, to increase buy-in.
- Prioritize and rationalize investments defined by a zero-trust strategy using zero-trust architecture development to define scope and a desired future state.
- Plan for operational budget increases, as many organizations expect a higher total cost of ownership to build, manage and maintain a zero-trust posture.
- Build a set of outcome-driven metrics to measure the current risk and track the progress of risk reduction over time.
Gartner Recommended Reading
Platform Engineering
Analysis By: Neha Agarwal, Paul Delory, Cary Pillers, Bill Blosen
Benefit Rating: Transformational
Market Penetration: More than 50% of target audience
Maturity: Mature mainstream
Definition:
Platform engineering is the discipline of building and operating a self-service developer platform for software development and delivery. A platform is a layer of tools, services, automations, and information maintained as products by a dedicated platform team, designed to support software developers or other engineers by abstracting unnecessary complexity. Its goal is to optimize developer productivity, centralize governance of AI capabilities, and accelerate delivery of customer value.
Why This Is Important
Digital‑empowered enterprises increasingly rely on complex tools, processes, and AI capabilities that must evolve based on business needs. Platform engineering abstracts this complexity by providing a self‑service, curated platform aligned with developer needs and internal requirements, like security and architecture. Using platform engineering increases developer productivity, improves quality, and enables faster delivery or value.
Business Impact
Platform engineering empowers product teams to deliver software value faster. It reduces the burden of underlying infrastructure construction and maintenance, and increases teams’ capacity to dedicate time to customer value and learning. Platform engineering voluntarily standardizes the chaos associated with custom software, which results in reduced risk in security, architecture, and compliance. It helps scale and manage the complexity of AI capabilities.
Drivers
- AI-enablement: Platforms provide paved roads, templates, and tools to enable scale AI, promote responsible AI usage, and manage the complexity of AI capabilities.
- Cognitive load: Adopting modern, distributed architectural patterns and software delivery practices means that developing and delivering software involves more tools, subsystems, and moving parts than ever before. This approach increases the burden on product teams, which must build a delivery system in addition to the software itself. Platform engineering reduces the load of infrastructure construction and maintenance.
- Scale: As more teams embrace modern software development practices and patterns, economies of scale emerge, which justifies creating a platform capability shared by multiple teams. This strategy is mostly of value at larger organizations where savings from platform engineering are clearer.
- Need for increased speed and agility: The need for speed and agility of software delivery is leading software organizations to pursue DevOps, which is a tighter collaboration of infrastructure and operations (I&O) and development teams, to drive faster delivery and increased deployment frequency. This approach enables organizations to respond rapidly to market changes, handle workload failures better, and tap into new market opportunities. Platform engineering enables this cross-team collaboration.
- Emerging platform construction tools: Many organizations have built internal platforms as homegrown efforts tailored to their unique needs, including using cloud-native application provisioning platforms and DevOps automation. Platforms generally are not transferable to other companies or sometimes even to other teams within the same company.
- Emerging developer portals: A healthy internal developer portal market is enabling front-end platforms, and Backstage is a popular open-source solution.
- Infrastructure modernization: Modernization efforts push I&O and development teams to adopt platform engineering to deliver more value to the business.
Obstacles
- Platform engineering is easily misunderstood: Traditional models of mandated platforms and DevOps toolchains can be relabeled and not achieve the true benefits of platform engineering.
- Lack of skills: Requires high in-demand skills of software engineering, product management, and modern infrastructure.
- Outdated management/governance models: Reliance on request-based provisioning models can create delays and complexity.
- Internal politics: Intraorganizational fights, no appetite to improve developer experience, or resistance from teams to give up their customized toolchains stalls efforts.
- Funding: Enterprises may refuse to fund platform engineering without a clear ROI. Attribution of the costs to user budgets is also tricky. Measuring the benefits/outcomes is critical.
- Scaling: It’s hard to scale and meet the constant need for platform evolution.
- Innovation: Platform engineering has not kept up with the pace of AI and internal developer portal innovation has stagnated.
User Recommendations
- Begin by setting up a platform team with aligned stakeholders and a product owner to guide platform-building efforts with the thinnest viable platforms for the complex infrastructure underneath cloud-native and distributed applications, including technologies like containers and Kubernetes.
- Enable shift-left and shift-right security within DevOps pipeline platforms, which will provide a compelling, paved road to engineers.
- Embed architectural guardrails, compliance controls, and any other nonfunctional requirements into the platform to further pave the road for developers.
- Refrain from expecting to buy or build a complete platform, as it is unlikely that any commercially available tool will provide the entirety of the platform you need.
- Implement an internal developer portal, which enables self-service discovery and access to internal developer platform capabilities. Consider the Backstage open-source solution, if resources permit, or other commercial tools.
Gartner Recommended Reading
Application Shielding
Analysis By: William Dupre, Dionisio Zumerle
Benefit Rating: Moderate
Market Penetration: 5% to 20% of target audience
Maturity: Adolescent
Definition:
Application shielding prevents and detects attacks such as tampering and reverse engineering of mobile apps. It is an in-app protection technology, meaning its capabilities are implemented directly within the application, rather than inline or on the hosting system.
Why This Is Important
Mobile applications move software logic and place sensitive data on the user devices. These applications expose functionality that, unless shielded, can lead to attacks such as data exfiltration from the app or its back end, and fraud against the user or the application. Application shielding is an important security measure when applications convey or store sensitive data or enable payments.
Business Impact
Application shielding protects an enterprise’s mobile applications when running on untrusted devices from cloning, information leakage, fraud, intellectual property (IP) theft and other forms of abuse. Besides helping to achieve regulatory compliance, it can be used in industries such as financial services and online retail by hardening applications, which enables the organization to minimize restrictions for its customers.
Drivers
- Innovation for application shielding revolves around two broad families of functionality to address current mobile application security threats: hardening and antitampering.
- Hardening hinders the attacker from stealing information (such as IP or credentials) or cloning the application by making reverse engineering harder. Hardening includes techniques such as code obfuscation and white-box cryptography.
- Antitampering performs reconnaissance of the environment the application runs in to identify potential risks. Antitampering includes techniques such as detecting emulation, rooting and debugging.
- Adoption is common for consumer-facing mobile applications in industry verticals such as financial services, online retail, healthcare, insurance, gaming, entertainment and automotive. Application shielding protects mobile applications, even ones that run on untrusted devices.
- Current attacks often use functionalities such as accessibility services or remote assistance to perform fraudulent actions against customer victims on mobile devices. Application shielding can detect potentially malicious applications and services and restrict their access.
- Evolving native application protection capabilities, especially from Android’s Play Integrity API and iOS’s App Attest, are making it possible for organizations to add application shielding functionality, albeit less specialized, without requiring them to acquire specialized products.
Obstacles
- To be effective, application shielding techniques must constantly evolve and keep up with the latest attacks, making application shielding a research-intensive discipline with products perceived as costly by mainstream organizations.
- Some technology-savvy security and development practitioners are not familiar with application shielding. Even if the risks they address may be clear, the techniques and efficacy to mitigate these risks are not apparent to end users.
- Most application shielding measures function as deterrence measures; obfuscation and other protections are possible to defeat with enough time and persistence.
User Recommendations
- Identify critical apps that store or access sensitive information (personal or health information, payment data or IP) and run in untrusted environments (for example, on customer devices).
- Use shielding measures natively offered by iOS and Android where possible. In high-security scenarios, complement native controls with specialized products that offer code obfuscation, malware detection and compromised device detection.
- Adopt a commercial application shielding product if your organization is in the financial services, online retail, gaming, insurance or healthcare industry verticals.
- Prefer postcoding implementation when you do not have access to the source code or do not want to impact the development life cycle. Favor implementation during development when you require complex functionality such as white-box cryptography and have access to the source code.
Sample Vendors
Appdome; Digital.ai; DoveRunner; Guardsquare; Licel; OneSpan (Build38); PreEmptive; Promon; Verimatrix; Zimperium
Gartner Recommended Reading
Reachability Analysis
Analysis By: Aaron Lord
Benefit Rating: High
Market Penetration: More than 50% of target audience
Maturity: Early mainstream
Definition:
Reachability analysis in security testing is a method that focuses on identifying and prioritizing vulnerabilities based on whether they are reachable or exploitable within a given application’s code. Used in conjunction with static application security testing (SAST) and software composition analysis (SCA), reachability analysis will contextualize vulnerability management by revealing what vulnerabilities realistically affect application workloads.
Why This Is Important
Organizations are overburdened with security vulnerabilities in their backlogs and require solutions to reduce their “mountains” into “molehills.” Open-source and third-party components may contain a long list of vulnerabilities, but not all of them directly impact your codebase. Reachability analysis helps in triaging the vulnerabilities based on their exploitability.
Business Impact
Besides the risk of security issues becoming security incidents, developers are reserving more hours for remediation, taking time away from new revenue-driving features. For cybersecurity personnel, this leads to more frustration and lower morale when dealing with the security posture of software. Reachability analysis therefore makes both software engineers and security engineers more effective.
Drivers
- Strong security vulnerability management now requires dynamic prioritization of issues using organizational context, rather than only relying on third-party standards, like the Common Vulnerability Scoring System (CVSS).
- Increased usage of open-source and third-party software with known vulnerabilities is contributing to security findings that further bloat security and development backlogs.
- A big portion of third-party code is onboarded, but never actually invoked during runtime. Therefore, most of the vulnerabilities present in third-party components are not directly exploitable. By postponing the remediation of such vulnerabilities, developers can prioritize resolving the most immediate risks while minimizing impact on the current sprint.
- Reachability analysis has become a requirement for security tooling that scans for vulnerabilities, putting security tools that do not have reachability analysis out of the market.
- Increasing numbers of vulnerabilities and complexity from AI coding agents are exacerbating the need to manage vulnerabilities long-term.
Obstacles
- Reachability analysis can add an additional layer of tests to currently existing security tooling that needs management and configuration.
- When utilized at runtime, reachability analysis instruments the workload and not the application directly. This adds a minor amount of performance overhead to the execution.
- Reachability analysis can produce a false sense of security, as unreachable vulnerabilities are still risks in the codebase; software organizations end up ignoring them, allowing them to accumulate in backlogs, and adding to technical debt.
User Recommendations
- Use reachability analysis in conjunction with static security scanning methods (i.e., SAST and SCA) to achieve more accurate findings from these methods.
- Use the contextualization properties of reachability analysis to improve software bill of materials (SBOMs) with Vulnerability Exploitability eXchange (VEX) data.
- Ensure that engineering or security teams managing SAST or SCA tooling are capable of taking on the minor additional overhead of configuring reachability analysis tests.
- Unreachable vulnerabilities are still a risk, so continue to prioritize resolving unreachable vulnerabilities through strategic technical debt management.
Sample Vendors
Backslash; Cisco; Endor Labs; Insignary; Kodem; Lineaje; Mend.io; Oligo Security; Root.io; Semgrep
Gartner Recommended Reading
Secure Coding Training
Analysis By: Aaron Lord, Manjunath Bhat
Benefit Rating: High
Market Penetration: 20% to 50% of target audience
Maturity: Early mainstream
Definition:
Secure coding training raises developer awareness of the impact — and enables the prevention — of vulnerabilities in source code. Developers receive secure coding training using different methods like just-in-time training, gamified lessons, workshops, and challenges.
Why This Is Important
In the 2026 Gartner Software Engineering Survey, 68% of software engineering leaders stated that application security is highly important to deliver software that meets current goals and requirements. Secure coding skills are often missing from general software engineering education, and what is considered secure code is a moving target. AI coding tools like Anthropic Claude and Github Copilot are making secure coding skills more important than ever to ensure the security of AI generated code.
Business Impact
Security issues in software will lead to undesirable outcomes, such as longer lead times to the deployment of new features and an increase in the risk exposure of vulnerabilities that are left unaddressed. Longer lead times for deployment impacts the business’ ability to meet customer needs, and vulnerabilities in applications inevitably result in a security incident or breach that harms customer trust and could lead to fines levied against the organization.
Drivers
- Application security is consistently a major concern for software organizations.
- Developers lacking security skills and knowledge produce unsecured applications by introducing vulnerable code, third-party components, and infrastructure misconfigurations.
- Staying up-to-date with secure coding practices will help reduce the risk of software vulnerability exposures by reducing the volume of vulnerabilities and shortening the time to remediate issues.
- The proliferation of AI coding agents such as Github Copilot and OpenAI Codex is leading to skills degradation for software engineers.
- Organizations that leverage AI coding agents are driving the need for more secure coding training to review the output of these agents.
Obstacles
- Just like any approach to teaching, different types of secure coding training (such as presentation, tests, and workshops) work better or worse for certain individuals.
- When training is assigned annually, dropping knowledge retention between training sessions may lead to more vulnerable applications.
- Offerings and pricing models for secure coding training can vary widely, making it difficult to understand what is needed.
- Integration for secure coding training tools remains a challenge that is exacerbated by the variance of tools and processes that are present in many organizations.
User Recommendations
- Collaborate with security leadership to form strategies that build security skills within software engineering teams.
- Choose a secure coding training vendor that offers training that matches the organization’s technology stacks, programming languages, and development frameworks.
- Create dedicated time for software engineers for training activities outside of their day-to-day work, and measure the success to get buy-in from the leadership.
- Use a training platform that offers workshops for improved engagement and emphasizes peer-to-peer knowledge sharing.
- Evaluate if secure coding training tools offer multilingual support for engineers across multiple regions.
- Implement learning for software engineers organically by integrating microtraining into the software development life cycle.
- Utilize built-in learning management systems (LMS) as a tool to track training progress.
Sample Vendors
Avatao; Black Duck; Checkmarx (Codebashing); Immersive; Secure Code Warrior; Security Compass; SecureFlag; Security Journey; Snyk; Veracode
Gartner Recommended Reading
Appendixes
Hype Cycle Phases, Benefit Ratings and Maturity Levels
Hype Cycle Phases
Phase | Definition |
Innovation Trigger | A breakthrough, public demonstration, product launch or other event generates significant media and industry interest. |
Peak of Inflated Expectations | During this phase of overenthusiasm and unrealistic projections, a flurry of well-publicized activity by technology leaders results in some successes, but more failures, as the innovation is pushed to its limits. The only enterprises making money are conference organizers and content publishers. |
Trough of Disillusionment | Because the innovation does not live up to its overinflated expectations, it rapidly becomes unfashionable. Media interest wanes, except for a few cautionary tales. |
Slope of Enlightenment | Focused experimentation and solid hard work by an increasingly diverse range of organizations lead to a true understanding of the innovation’s applicability, risks and benefits. Commercial off-the-shelf methodologies and tools ease the development process. |
Plateau of Productivity | The real-world benefits of the innovation are demonstrated and accepted. Tools and methodologies are increasingly stable as they enter their second and third generations. Growing numbers of organizations feel comfortable with the reduced level of risk; the rapid growth phase of adoption begins. Approximately 20% of the technology’s target audience has adopted or is adopting the technology as it enters this phase. |
Years to Mainstream Adoption | The time required for the innovation to reach the Plateau of Productivity. |
Source: Gartner
Benefit Ratings
Benefit Rating | Definition |
Transformational | Enables new ways of doing business across industries that will result in major shifts in industry dynamics |
High | Enables new ways of performing horizontal or vertical processes that will result in significantly increased revenue or cost savings for an enterprise |
Moderate | Provides incremental improvements to established processes that will result in increased revenue or cost savings for an enterprise |
Low | Slightly improves processes (for example, improved user experience) that will be difficult to translate into increased revenue or cost savings |
Source: Gartner
Maturity Levels
Maturity Levels | Status | Products/Vendors |
Embryonic | In labs | None |
Emerging | Commercialization by vendors Pilots and deployments by industry leaders | First generation High price Much customization |
Adolescent | Maturing technology capabilities and process understanding Uptake beyond early adopters | Second generation Less customization |
Early mainstream | Proven technology Vendors, technology and adoption rapidly evolving | Third generation More out-of-box methodologies |
Mature mainstream | Robust technology Not much evolution in vendors or technology | Several dominant vendors |
Legacy | Not appropriate for new developments Cost of migration constrains replacement | Maintenance revenue focus |
Obsolete | Rarely used | Used/resale market only |
Source: Gartner