OWASP Changed. The Application Security Stack Needs to Catch Up.

For years, the OWASP Top 10 gave security leaders a practical way to understand the most important risks in web applications. It helped teams align around familiar categories like injection, broken authentication, sensitive data exposure, cross-site scripting, and insecure deserialization.

But the OWASP Top 10 has never just been a checklist. It is also a signal.

When the list changes, it tells us something about how software is changing, how attackers are changing, and where existing security controls are starting to lose visibility.

The shift from OWASP 2017 to OWASP 2025 is not cosmetic. It reflects a much deeper change in the center of gravity for application security.

OWASP changed. Software development changed. AI changed.

The security stack now has to change with it.

The application is no longer just the code your team writes.

The biggest change in software development over the last decade is that applications are now assembled as much as they are written.

Modern applications are built from open-source packages, transitive dependencies, frameworks, SDKs, parsers, serializers, template engines, containers, CI/CD actions, cloud services, microservices, queues, webhooks, API-to-API traffic, and increasingly, AI-generated code that pulls in even more components.

This is not a small part of the application. It is the application.

The Linux Foundation has estimated that free and open-source software makes up 70% to 90% of modern software solutions. Black Duck’s 2025 OSSRA reporting found that 97% of audited codebases contained open source.  

For CISOs, that changes the core question: “Did our developers write insecure code?”

The better question is, “What software are we actually running, what does it do at runtime, and can we trust it?”

OWASP’s center of gravity moved from web bugs to software trust.

In 2017, the OWASP Top 10 still reflected many classic web application security concerns: injection, broken authentication, sensitive data exposure, XXE, cross-site scripting, insecure deserialization, components with known vulnerabilities, and insufficient logging and monitoring.

Those risks still matter, but the framing has expanded.

In OWASP 2025, “Software Supply Chain Failures” is now A03. OWASP notes that the category has grown beyond known vulnerable components to include broader software supply chain failures. It was also top-ranked in the community survey, with 50% of respondents ranking it number one.  

That matters because supply chain risk is no longer just about whether a package has a CVE. It is about whether the organization understands the software it depends on, how that software enters the environment, whether it is trustworthy, and what it is capable of doing when it runs.

This is a major shift for security leaders.

A component is not just “a library.” It can parse data, interpret input, touch the file system, open network connections, call cloud services, load native code, deserialize objects, spawn processes, or handle secrets.

Every component becomes a potential execution boundary. Every execution boundary becomes part of the attack surface.

Input is no longer just HTTP.

A lot of application security tooling was built around the front door of the application.

• What request came in?
• What payload was sent?
• What route was targeted?
• What did the WAF block?

That model still matters, but it is incomplete.

Modern applications receive input from HTTP requests, internal APIs, partner APIs, webhooks, files, uploads, logs, queues, Kafka topics, SQS messages, SDK responses, cloud metadata, tokens, secrets, configuration files, templates, parsers, deserializers, and AI agents.

Some of the most important application behavior now begins far away from the perimeter. It starts when one component receives data from another component, service, queue, file, cloud provider, automation workflow, or AI system.

This is why “injection” is no longer just SQL injection.

It is unsafe interpretation across thousands of boundaries.

A template engine can interpret unsafe input. A deserializer can load an unexpected object. A query builder can assemble logic in an unintended way. A parser can enter an exceptional state. A cloud SDK can receive poisoned runtime data. A library can open a network connection it should never open.

For CISOs, the operational question becomes much more specific: What is this component allowed to do inside my application?

AI compresses the exploitation timeline.

AI does not create an entirely new class of application risk. It accelerates the economics of finding, understanding, and weaponizing risk.

Public components are easier to study. Vulnerable patterns are easier to search for. Exploit hypotheses are easier to test. Attack chains are easier to adapt.

That matters because so much of the modern application is made of public software.

In 2026, reporting on Anthropic’s Claude Opus 4.6 described more than 500 high-severity vulnerabilities found across production open-source codebases, including issues that had gone undetected for years.  

Security teams should not read that as a reason to panic. They should read it as a warning about timelines.

If AI can help defenders find weaknesses faster, it can also help attackers reason through public components, package behavior, exploit chains, and reachable attack paths faster.

That makes patch-only response too slow by itself. It also makes CVE-only prioritization too narrow by itself.

Security leaders need to know not only what is vulnerable, but what is loaded, reachable, sensitive, and capable of dangerous behavior in production.

The existing AppSec stack still matters, but it was built for different layers.

This is where the conversation often becomes too binary.

The answer is not to replace SAST, SCA, WAF, EDR, SIEM, CNAPP, or ASPM. These tools still matter. The real issue is understanding what each tool can and cannot be the primary control for.

SAST is useful for identifying insecure code patterns before deployment.
SCA is useful for inventorying dependencies and known vulnerable packages.
WAF is useful for inspecting and filtering traffic at the edge.
EDR is useful for detecting host and process-level behavior.
SIEM is useful for correlation and investigation.
ASPM is useful for organizing AppSec findings and workflows.

But none of these categories fully answer the runtime trust question inside the application:

• What actually loaded?
• What actually executed?
• Which component caused the behavior?
• Which function and call chain were involved?
• Was this expected?
• Was the vulnerable path reachable?
• Should this action be blocked now?

That is the missing layer in many application security programs.

Not another inventory.

Not another severity score.

Runtime evidence.

How CISOs should rethink AppSec priorities.

The evolution of OWASP should push security leaders to ask sharper questions about their application security programs.

Instead of asking only whether the organization has SCA coverage, ask whether the team can prove which vulnerable components are actually loaded and reachable in production.

Instead of asking only whether the organization has WAF rules, ask whether the team can see what happens after a request is accepted by the application.

Instead of asking only whether EDR is deployed on servers, ask whether runtime behavior can be attributed back to the application component, function, and call chain that caused it.

Instead of asking only how many critical CVEs are open, ask which critical risks can actually execute, touch sensitive paths, or trigger dangerous behavior.

Instead of asking only whether the event was logged, ask whether the team has enough application context to respond without days of manual investigation.

These questions are not academic. They determine whether AppSec and security operations can separate theoretical exposure from active risk.

Runtime application trust is becoming the new control plane for AppSec.

The next phase of application security will be defined by runtime application trust.

Security teams need to map what loads and executes, understand what each component does, prioritize what is reachable and risky, patch what matters first, and prevent active exploitation when patching cannot happen fast enough.

That does not make the existing stack obsolete. It makes the existing stack more accurate.

SAST findings become more useful when they are connected to runtime paths. SCA findings become more useful when they are connected to loaded and reachable components. WAF alerts become more useful when teams can see what the application actually did after the request was accepted. EDR events become more useful when they can be tied back to the library, function, and call chain that caused them.

This is the direction OWASP is pointing toward.

The future of application security is not just finding more issues. It is understanding what the application is actually doing.

The ground moved.

Now the stack has to move with it.