Blog
The Stryker Cybersecurity Breach: Why Business Resilience Must Be Architected, Not Assumed
Read More
Application security has grown dramatically to a core business risk. As organizations accelerate software development, adopt cloud-native architectures, and increasingly rely on open-source and AI-generated code, the application layer has become one of the most targeted—and vulnerable—parts of the enterprise technology stack.
In a recent webinar, Akash Tembe, Sayers Application Security Subject Matter Expert, walked through what application security really means today, why it matters to customers, and how modern tooling—especially Application Security Posture Management (ASPM)—is reshaping how organizations manage risk. His discussion tied together development workflows, vendor ecosystems, and real-world customer success stories to provide a practical lens on AppSec strategy.
At its core, an application is no longer just a monolithic piece of code running on a server. Modern applications are complex systems made up of many interconnected components. This broader ecosystem is often referred to as the application stack, or “app stack.”
The app stack typically includes:
• Custom application code written by developers
• Open-source and third-party libraries
• APIs and microservices
• Containers and container images
• Infrastructure-as-Code (IaC) configurations
• CI/CD pipelines and build systems
• Runtime environments and cloud infrastructure
Each layer introduces potential risk. Vulnerabilities may not come from the code developers write themselves, but from the libraries they import, the containers they deploy, or the configurations they rely on. As Tembe emphasized, application security is no longer just about scanning code—it’s about understanding and securing everything that contributes to how an application is built, deployed, and run.
This complexity is exactly why traditional, siloed security approaches are no longer sufficient.
Tembe outlined the major technical pillars that make up modern application security. Each plays a distinct role, but none are effective in isolation.
• Static Application Security Testing (SAST)
SAST tools analyze source code to identify vulnerabilities early in the development lifecycle. They help catch issues like insecure coding patterns before applications ever reach production.
• Dynamic Application Security Testing (DAST)
DAST tools test running applications, simulating real-world attacks to uncover vulnerabilities that only appear at runtime.
• Software Composition Analysis (SCA)
SCA tools focus on open-source and third-party dependencies. Given how heavily modern applications rely on external libraries, SCA is critical for identifying known vulnerabilities and tracking license obligations.
• Container and Cloud-Native Security
With containers now a standard deployment model, security tools must analyze container images, registries, and runtime configurations. This includes ensuring base images are secure and free of known vulnerabilities.
• Infrastructure-as-Code (IaC) Security
IaC defines infrastructure through code, which means misconfigurations can be deployed at scale just as easily as good configurations. IaC security tools identify risky patterns before they reach production.
Together, these capabilities form the technical foundation of application security—but managing them individually can quickly become overwhelming.
One of the most important themes of the session was meeting developers where they work.
To be effective, application security tools must integrate directly into:
• Integrated Development Environments (IDEs)
• CI/CD pipelines
• Build and deployment workflows
When security is embedded into the development process, vulnerabilities can be identified and addressed early—before they become expensive or disruptive to fix. This approach also reduces friction between security and development teams, shifting AppSec from a gatekeeper model to a shared responsibility model.
Tembe emphasized that the goal is not to slow developers down, but to enable them to build secure software by default.
The Role of ASPM: Bringing It All Together
As organizations adopt multiple AppSec tools, a new challenge emerges: visibility and prioritization.
Many teams struggle with:
• Managing dozens of tools across SAST, DAST, SCA, and container security
• Understanding which vulnerabilities matter most
• Connecting technical findings to business risk
This is where Application Security Posture Management (ASPM) comes in.
ASPM platforms aggregate data from multiple AppSec tools into a single view, providing:
• Centralized visibility into application risk
• Context-aware vulnerability prioritization
• Insights into how vulnerabilities impact real applications and business services
Rather than drowning in alerts, teams can focus on what matters most—reducing risk in a structured, measurable way. For customers overwhelmed by tool sprawl, ASPM becomes a force multiplier.
AI has fundamentally changed how software is written. Developers are increasingly relying on AI tools to generate code, dramatically improving speed and efficiency—but also introducing new security risks alongside those gains.
According to Veracode’s 2025 GenAI Code Security Report, 45% of AI generated code introduced risky security vulnerabilities when analyzed across real world use cases. In other words, nearly half the time, AI models made insecure choices even when secure alternatives existed.
This shift is happening fast, and governance isn’t keeping up. In Checkmarx’s “Future of Application Security in the Era of AI” report, 34% of respondents said that more than 60% of their code is now AI generated, yet only 18% have policies governing the use of AI generated code. That creates a massive visibility and control gap inside development pipelines.
Even more concerning, the same Checkmarx research found that 81% of organizations knowingly ship vulnerable code, often due to business pressure and development speed outweighing security review.
Tembe encouraged starting conversations in organizations around:
• How AI-generated code is being reviewed and secured
• Whether guardrails exist to prevent vulnerable or outdated code from entering production
• Whether policies govern the use of AI-generated code
Without proper controls, AI can inadvertently introduce deprecated libraries or insecure patterns at scale. AppSec guardrails help ensure innovation doesn’t come at the cost of security.
Open-source software is foundational to modern development, but it comes with responsibilities.
Tembe highlighted the importance of understanding:
• Which third-party components are being used
• What vulnerabilities those components introduce
• What licenses are attached to each dependency
Every open-source library includes a license that defines how it can be used, modified, and distributed. Failing to track these obligations can create legal and compliance risk alongside security risk.
SCA tools play a critical role in maintaining this visibility and helping organizations manage their software supply chain responsibly.
A recurring theme throughout the session was focus.
Many organizations ask:
• Are we using too many tools?
• Do we know which risks matter most?
• Are we spending time fixing the right problems?
These questions open the door to discussions about ASPM, risk-based prioritization, and security strategy. Rather than reacting to every alert, mature AppSec programs align remediation efforts with business impact.
Final Thoughts
Application security is no longer a standalone technical discipline. It sits at the intersection of development, operations, security, and business risk.
Organizations that succeed in AppSec:
• Embed security into development workflows
• Leverage the right mix of platforms and specialized tools
• Prioritize risk through visibility and context
• Prepare for emerging challenges like AI-generated code
For organizations navigating increasing complexity, application security isn’t just about finding vulnerabilities—it’s about managing posture, reducing risk, and enabling innovation safely.
