The SOAR Framework: 4 Stages of Rolling Out DAST at Scale

This year, we’ve seen AI-accelerated development fundamentally change the game for AppSec teams. Attack surfaces are expanding faster than security teams can assess and reduce risk. Development teams are shipping code at a pace that would’ve seemed impossible five years ago. And somewhere in the middle, AppSec teams are trying to figure out how to scale their programs without scaling headcount proportionally.

After six years of working with hundreds of AppSec teams, we’ve learned one thing for certain: having a great DAST tool is only half the battle. The other half? Actually getting it rolled out, adopted, and scaled across your organization in a way that doesn’t drive your developers (or yourself) completely insane.

Shift-left DAST is how you do it. But most teams approach DAST implementation as a purely technical problem. They pick a tool, run some scans, and then wonder why adoption stalls after a few pilot apps. Sound familiar?

Why Most DAST Implementations Fail to Scale

We’ve seen this pattern play out dozens of times. A security team gets executive approval for a DAST solution, runs a successful proof of concept, and then… crickets. Six months later, they’re still testing the same three applications they started with.

There’s nothing wrong with the technology. The problem is that comprehensive, scalable DAST coverage requires an intentional program that combines people, processes, and technology from day one. You need a framework that addresses not just the “what” (which tool to use) but the “how” (getting teams to actually use it) and the “why” (proving ongoing value to leadership).

That’s exactly why we built the SOAR Framework.

Introducing the SOAR Framework for Scaling DAST

The SOAR Framework is built from real-world experience working with hundreds of AppSec teams over the past six years. It’s a practical, battle-tested approach to implementing and scaling DAST (and by extension, your broader AppSec testing program) across organizations of all sizes.

SOAR stands for:

• Scope Project & Secure Buy-In
• Onboard & Optimize Cross-Team Process
• Automate & Amplify Testing Coverage
• Reinforce & Report on Program Success

Each phase builds on the previous one, addressing the critical challenges that trip up most DAST implementations: securing genuine stakeholder buy-in, proving value with an effective pilot, scaling without creating bottlenecks, and maintaining momentum through clear metrics. Let’s walk through each stage.

Scope Project & Secure Buy-In

This is where it all starts—before deploying any tools. Without executive sponsorship and engineering buy-in, security initiatives stall. You need explicit mandates (or at least solid sponsorship) to secure dedicated resources and get genuine stakeholder alignment.

We’re not saying get a budget approved and call it a day. You need to build a coalition of support that extends from the office of the CISO (or even CIO/CEO) down to the development teams who are responsible for actually fixing vulnerabilities surfaced by AppSec testing. 

You’re essentially answering three critical questions: 

1. Why are we doing this? 
2. Who’s responsible for what? 
3. And how will we know if it’s working?

As you scope your project, understand that shift-left DAST is fundamentally different from traditional DAST. Traditional DAST was built for security teams to test applications in production. Shift-left DAST must integrate seamlessly into developer workflows, run fast enough for CI/CD pipelines, and surface findings that developers can actually fix. 

Get our full list of requirements in the framework.

Pro Tips for Success

Have engineering leaders announce the program, not just AppSec. This signals shared ownership and dramatically increases developer willingness to engage. When developers hear about a new security initiative from their VP of Engineering rather than from a security team they rarely interact with, it completely changes the tone.

Interview developers before pitching solutions. This is crucial. Spend time understanding their actual workflows, what security tools they already interact with, and what frustrates them about existing security processes. You’ll avoid tone-deaf approaches and build solutions that developers actually want to use.

Define “what good looks like” with numbers, not feelings. Don’t just say “we want better security.” Say “we want 75% of high-risk applications under active testing with 80% pre-production detection rate within 12 months.” Specific metrics give everyone a clear target to work toward.

Onboard & Optimize Cross-Team Process

Early and visible success builds momentum and trust. A well-executed pilot proves that security can work with development rather than blocking it, earning you the credibility needed for broader adoption across teams.

This is where the rubber meets the road. Your pilot phase is your chance to prove that shift-left DAST actually works in your environment, with your applications, and your development teams. Nail this phase, and you’ll have developers asking to join the program. Mess it up, and you’ll spend the next year fighting resistance.

The key focus during this phase is building your “Paved Road”—the standardized templates, documentation, and processes that will allow teams to self-onboard without requiring custom AppSec configuration for every new application. Without this foundation, you’ll create a bottleneck that prevents scaling beyond your pilot apps.

Pro Tips for Success

Assign a Program Manager who can effectively collaborate with technical teams and own the project end-to-end. It should be someone who goes beyond milestone tracking to work directly with developers, understand technical blockers, and remove obstacles.

Choose pilot apps with security-interested developers who’ll become early champions. Look for teams that have already expressed interest in security, or teams that have been burned by production incidents. These developers are motivated to make this work.

Tune ruthlessly for speed. Scans that take longer than 10 minutes lose developer trust fast. If your CI/CD pipeline normally takes 8 minutes and you add a 15-minute security scan, developers will find ways to bypass it. Aim for under 5 minutes whenever possible.

Fix vulnerabilities together in pairing sessions. Don’t just hand off a report. Sit down (virtually or in-person) with developers and fix a few vulnerabilities together. This builds relationships, helps you understand their context, and makes remediation feel collaborative rather than adversarial.

Automate & Amplify Testing Coverage

Scaling requires repeatable, automated processes that developers can own. Working with development teams to build a paved road for self-onboarding is the key to removing bottlenecks and scaling across the applications that actually matter.

This is where your program either achieves meaningful scale or plateaus at 5-10 applications indefinitely. The difference comes down to one critical question: Can teams onboard themselves, or does every new application require custom AppSec configuration help?

Choosing Your Scaling Path

After completing your pilot, you face a critical decision: how will you scale DAST across your organization?

There isn’t one right answer. The path you choose depends on your organizational readiness, available resources, and company culture. We’ve identified three distinct scaling paths that successful organizations take:

• Path 1: Champion-Led. Best for organizations building grassroots momentum without a strong executive mandate. Security Champions become evangelists within their development teams, and teams adopt testing iteratively at their own pace when they see peer success.
• Path 2: Governance-Driven. Best for organizations with executive sponsorship and established AppSec programs. Executive sponsorship makes DAST adoption a requirement, and teams onboard independently using standardized templates and documentation.
• Path 3: Platform-Automated. Best for highly mature organizations with sophisticated automation capabilities. Platform Engineering treats security testing as automated infrastructure that developers inherit as near-invisible infrastructure.

Pro Tips for Success

Champions need recognition and autonomy, not just extra responsibilities. Don’t treat security champions like it’s just one more thing on their plate. Give them visibility with leadership, provide them with resources and training, and recognize their contributions publicly.

Make onboarding so easy that teams feel behind if they’re not testing. The goal is to flip the script from “why do we have to do this?” to “we should probably be doing this.” When other teams are testing and yours isn’t, it should create positive peer pressure.

Automate everything: alerts, tickets, dashboards—manual processes don’t scale. If you find yourself manually creating Jira tickets for every finding, or manually checking which teams have integrated, or manually pulling metrics for reports, you’ve hit a scaling ceiling. Automate it.

Reinforce & Report on Program Success

Programs without metrics lose momentum. Clear measurement proves ROI, and continuous improvement sustains engagement as your application attack surface evolves and expands.

This is the maturity phase where your DAST program transitions from project to platform—from something you’re actively pushing to something that sustainably operates with appropriate oversight. You’re no longer convincing teams to adopt security testing; you’re optimizing a program that’s become part of how your organization builds software.

The Metrics That Matter

What gets measured gets funded. As your program matures, metrics transform from internal scorecards into strategic business assets. They prove you’re not just running scans—you’re systematically reducing risk, accelerating development, and scaling AppSec without scaling headcount.

We organize success metrics into three categories:

• Coverage & Adoption Metrics (“Are we testing what matters?”)
• Risk Reduction Metrics (“Are we actually reducing risk?”)
• Efficiency & Health Metrics (“Are we scaling effectively?”)

Get all 12 of the actual metrics in the SOAR Framework

Pro Tips for Success

• Celebrate fixes publicly, not just report vulnerabilities. Send a monthly roundup highlighting teams that fixed the most vulnerabilities, improved their security posture, or onboarded new applications. Positive reinforcement works better than shame.
• Tie metrics to business outcomes that leadership cares about. Don’t just say “we scanned 50 applications.” Say “we prevented 12 high-severity vulnerabilities from reaching production, avoiding potential incidents that could have impacted customer trust and required engineering response time.”
• Budget for continuous improvement. Programs stagnate without ongoing investment. Plan to allocate resources for template updates, new integrations, training refreshes, and tooling improvements. Security isn’t a one-time implementation.

Get the Complete SOAR Framework

This post covers the basics, but the complete framework has so much more. We’ve documented detailed guidance on:

• Milestones, meetings, and red flags for each stage
• Defining requirements for shift-left DAST that actually work in CI/CD pipelines
• The six milestones for onboarding DAST with reusable templates
• Detailed breakdowns of all three scaling paths with prerequisites and decision frameworks
• Complete metrics dashboard templates with benchmarks for each program phase
• Real-world case studies and lessons learned from customer implementations

Ready to shift left and scale your AppSec program? Schedule a demo to learn how StackHawk can help.