Security budgets are growing, and security teams are expanding, yet Gartner’s 2026 Application Security Strategy report found that 43% of organizations are still operating at the lowest level of AppSec maturity. The figure suggests that more investment in security tooling and resources doesn’t necessarily lead to greater AppSec maturity.
The Meaning of AppSec Maturity
AppSec maturity describes how deeply security is integrated into the way software is built, rather than how much security tooling an organization has deployed.
At the low end of the maturity spectrum, security is reactive. Vulnerabilities are found late, usually after code has been written and even after it has already shipped. Security teams work largely separately from development teams, reviewing finished work rather than influencing how software is designed and built. When findings arise, developers often lack the context to address them efficiently, which creates backlogs and delayed releases.
At higher maturity levels, security is a continuous part of development. Developers understand the vulnerability classes relevant to what they build, and they define security requirements before writing code. Teams are then able to find and fix vulnerabilities in a shorter time frame so context is not lost. Security does not slow delivery because it is built into the process, not applied afterward.
The Limits of Security Tooling
The standard response to an AppSec problem has been to add more tooling, whether that’s SAST scanners, DAST platforms, software composition analysis, or ASPM. While it’s true that they have automated more of the work of finding vulnerabilities, they don’t change how developers work.
Access to better tools does not change a team’s maturity level if the ability to act on findings has not developed. All that happens is that they now have a longer list of findings. However, if developers cannot interpret those findings, do not understand why they are risky, and have no practiced sense of how to fix them, the tooling has not changed the situation.
It’s for this reason that organizations can increase their security tool spend every year while remaining at the same maturity level. Security tools measure and report on what a development process produces, but do not by themselves change how that process works.
Developer Security Competency
What distinguishes higher-maturity organizations is the security competency of their developers, along with the sophistication of their tooling.
When developers understand the vulnerability classes relevant to their work, for example, how access control flaws are introduced and where secrets management fails, security becomes part of how they think about building software. That understanding changes what they question during design, how they write code, and what they catch in code review, including the logic flaws that scanners don’t usually detect.
This type of experience does not happen through awareness training or annual compliance modules, but from repeated, practical exposure to real vulnerability scenarios, feedback on how developers respond to them, and enough variation to build pattern recognition. In the long run, it turns security knowledge into a practical development skill that can influence decisions before vulnerabilities are found.
The Steps Toward Higher Maturity
For security leaders trying to move their organization up the maturity spectrum, a few factors mark the move from reactive to proactive.
The first is bringing security requirements into the design phase. When threat modeling is part of how features are planned rather than reviewed afterward, the risks with the greatest impact are identified and addressed before any code is written.
Next, investing in developer security competency as an ongoing program is important. A training course, now and then, does not build lasting capability. There needs to be structured learning linked to the vulnerability categories most relevant to what a team builds, with progress tracked over time and training directed to the areas that need it, rather than delivered as generic content.
Finally, measurement needs to reflect whether training is working. Recording completion rates only confirms that developers completed the training, but not their capability. In contrast, performance data from hands-on assessments shows whether developers can identify and fix the vulnerabilities the program was designed to address. Using performance data, organizations can make evidence-based decisions about where to focus next. Those who track only the completion rates could see the same vulnerability categories keep appearing.
The Effect of AI-Generated Code on AppSec Maturity
Organizations at the lowest maturity levels are now contending with a challenge that has made their position more difficult to maintain. AI coding assistants have accelerated development and increased code volume; however, the question is whether organizations are equipped to manage the security implications.
Veracode’s 2026 GenAI Code Security Report found that AI now writes roughly half of all committed code in organizations that have adopted AI coding tools. Nearly 44% of code-generation tasks introduce known security vulnerabilities, a figure that has not improved despite a year of model advances. As AI-generated code volumes grow, organizations also need to account for the security risks that come with that additional code.
The vulnerability categories where models perform worst included cross-site scripting and log injection, with security pass rates of 15% and 13%, respectively. These are precisely the issues that require a developer’s understanding of how user input flows through a system.
If developer security competency exists, AI-generated code is evaluated before it ships, but if it does not, AI-assisted development increases the volume of unreviewed risks entering production.
Building the Capability That Advances Maturity
Higher maturity comes from giving development teams the knowledge and experience to make better security decisions as they build software. SecureFlag helps organizations build the security competency of those writing and reviewing code, something security tooling cannot provide on its own.
Hands-on labs place developers in real development environments, where they work with realistic vulnerability scenarios across the categories most relevant to their work. SecureFlag also provides practical training for AI-assisted development, helping developers prompt securely and evaluate AI-generated code for security risks.
They develop an understanding of what causes vulnerabilities and how to fix them. Performance is tracked over time, giving security leaders insight into where competency is developing and where specific attention is needed.
ThreatCanvas, SecureFlag’s automated threat modeling solution, enables teams to bring security into the design phase by modeling how systems manage trust, authorization, and data flow before coding and identifying the risks worth addressing before they become findings.
Talk to our team to see how SecureFlag helps organizations build AppSec maturity.
