Notifications
Clear all
Topic starter
02/08/2026 9:41 am
TL;DR: AI-accelerated development is widening attack surfaces faster than AppSec teams can assess them, and StackHawk argues most DAST rollouts fail because they treat adoption as a tooling problem rather than a programme problem. The operational lesson is that scale depends on buy-in, workflow fit, automation, and reporting discipline, not scan volume alone.
NHIMG editorial — based on content published by StackHawk: The SOAR Framework, 4 Stages of Rolling Out DAST at Scale
Questions worth separating out
Q: How should security teams scale DAST across many application teams?
A: They should standardise onboarding, choose a clear scaling model, and remove manual dependency wherever possible.
Q: Why do DAST rollouts fail when the technology works fine in pilot testing?
A: Pilot success often hides the real problem, which is organisational fit.
Q: What do AppSec teams get wrong about shift-left testing at scale?
A: They often treat shift-left as a tool deployment rather than a workflow change.
Practitioner guidance
- Define a scaling path before broad rollout Choose whether the programme will be champion-led, governance-driven, or platform-automated before expanding beyond the pilot.
- Build a paved road for self-onboarding Create reusable templates, standard documentation, and consistent alert routing so new teams can adopt DAST without bespoke security engineering help.
- Set scan performance thresholds that developers will tolerate Keep security checks fast enough to fit normal delivery workflows, and measure whether scan times are creating bypass behaviour.
What's in the full article
StackHawk's full article covers the operational detail this post intentionally leaves for the source:
- Detailed milestone sequence for each SOAR phase, including the handoffs between security, engineering, and leadership
- Framework for deciding whether champion-led, governance-driven, or platform-automated scaling best fits your organisation
- Exact metrics set used to judge DAST programme maturity across coverage, risk reduction, and efficiency
- Practical guidance on the templates and reporting rhythm needed to keep adoption from stalling
👉 Read StackHawk's framework for scaling DAST across application teams →
DAST at scale: what AppSec teams need to fix beyond tooling?
Explore further
02/08/2026 12:35 pm
Programme design, not scanner selection, determines whether DAST scales. The article is right to treat rollout as an operating model problem because the technical capability is rarely the limiting factor. Teams that ignore stakeholder alignment, delivery integration, and ownership clarity end up with a tool that works in isolation but not in practice. For security leaders, the lesson is to design for adoption as carefully as for detection.
A question worth separating out:
Q: How do you know if a DAST programme is actually keeping up?
A: Look at setup time, scan duration, and where findings appear. If onboarding takes weeks, scans take hours, or results land outside developer tools, the programme is lagging behind delivery velocity. A working control reduces the gap between code change and verified security feedback.
👉 Read our full editorial: Scaling DAST in AppSec needs process, not just tooling
