Who should be accountable for adding and maintaining DAST configuration across repositories?

AppSec should own the testing standard and approved patterns, while developers should review repository-specific output, supply required secrets, and merge the final configuration. Security and engineering both have a role because DAST depends on application context. If ownership is unclear, onboarding stalls, coverage becomes inconsistent, and runtime testing remains a later-phase promise instead of a repeatable control.

Why This Matters for Security Teams

DAST configuration is not just a tooling task. It determines which applications are scanned, how authenticated flows are handled, where tests run, and whether results are actionable. When accountability is vague, teams often end up with duplicate profiles, missing credentials, or scans that technically run but never cover the paths that matter. That weakens both developer trust and security assurance, especially when DAST is meant to support release gates and continuous verification.

Security ownership also needs to be explicit because DAST sits between application security policy and repository-level implementation. AppSec typically defines the control standard, approved scan patterns, and escalation criteria, while engineering owns codebase-specific integration and maintenance. That division is consistent with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises accountable control operation rather than ambiguous shared responsibility.

In practice, many security teams encounter DAST ownership failures only after a release pipeline has already drifted away from the approved scan standard, rather than through intentional control design.

How It Works in Practice

The cleanest operating model is to separate policy ownership from repository execution. AppSec or platform security should define the baseline DAST configuration, including target scope, authentication method, exclusions, scan frequency, reporting thresholds, and evidence requirements. Development teams then apply that standard in each repository, because they are best placed to supply application-specific context such as environment variables, login flows, test accounts, and route exceptions. This aligns with broader secure engineering guidance in the OWASP Application Security Verification Standard, especially where testability and security validation must fit the application design.

In operational terms, a durable handoff usually includes:

• AppSec publishes a versioned DAST template or reference configuration.
• Developers implement repository-local settings and required secrets handling.
• Security reviews scan scope, false-positive handling, and policy exceptions.
• CI or release pipelines enforce that the approved configuration is present.
• Ownership is recorded in code, ticketing, or platform documentation so it survives team changes.

This model works best when DAST is treated as a governed control, not a one-time onboarding task. A shared ownership model is acceptable, but the accountabilities should not be shared equally. AppSec should own the testing standard and change control, while developers should own correct integration and ongoing maintenance inside the repository. If the environment includes complex authentication, ephemeral preview deployments, or microservices with frequently changing routes, the configuration must be reviewed more often, because the test harness can fail silently even when the pipeline appears healthy. These controls tend to break down when repositories are highly autonomous and security teams lack direct visibility into pipeline changes because scan configuration drift faster than review cycles.

Common Variations and Edge Cases

Tighter DAST governance often increases developer overhead, requiring organisations to balance consistency against delivery speed. That tradeoff becomes more visible in large mono-repos, federated engineering teams, and platform setups where one scan definition must serve many services. Best practice is evolving here: there is no universal standard for whether security should centrally maintain every repository file or only the approved baseline, but current guidance suggests central ownership of policy and local ownership of implementation is the most sustainable split.

Special cases also matter. In regulated environments, security may require stronger evidence of scan execution and exception handling, especially where NIST AI Risk Management Framework style governance principles are applied more broadly to software assurance programmes. For high-risk applications, AppSec may need to approve authentication material handling, rate limits, and safe testing windows. For externally facing systems, the configuration may also need coordination with abuse-prevention and monitoring controls so that scans are not mistaken for hostile activity. In contrast, very small teams may assign one engineer to maintain the repository file while AppSec reviews the pattern centrally, but that should still be documented as a control owner and an implementation owner.

The practical rule is simple: AppSec owns the standard, engineering owns the repo-level implementation, and both should be able to prove who changed what, when, and why. Where that split is not documented, DAST usually becomes someone else’s problem until the first missed finding, failed scan, or audit request forces ownership to be assigned retroactively.

Related resources from NHI Mgmt Group

• Who is accountable for enforcing supply chain security across repositories and teams?
• Who is accountable when identity security controls fail across team boundaries?
• Who is accountable when cyber crisis decisions stall across teams?
• Who is accountable when identity governance and enforcement are split across tools?