Who should own remediation when a DAST finding reveals exposed application paths?

Why This Matters for Security Teams

DAST findings often look simple at first glance, but exposed application paths can point to a wider control failure than a single code defect. The real question is not who ran the scan, but which layer failed: application routing, authentication, authorization, secrets handling, reverse proxy rules, or platform configuration. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames accountability around access control, system protection, and configuration management rather than scanner ownership alone.

This matters because misassigned remediation creates delay, duplicate work, and weak closure criteria. If the path is exposed due to an app route, the application team usually owns the fix. If the exposure comes from an auth bypass, leaked secret, or permissive gateway rule, AppSec, IAM, or platform engineering may need to act in parallel. Current guidance suggests that ownership should follow the failed control, not the discovery tool, especially when multiple teams contribute to the same attack surface. The same principle is increasingly relevant in AI-enabled environments, where automated reconnaissance can rapidly chain exposed paths into credential theft or lateral movement, as highlighted in the Anthropic — first AI-orchestrated cyber espionage campaign report.

In practice, many security teams encounter unclear ownership only after a scanner alert has already been escalated into a production incident.

How It Works in Practice

The cleanest way to assign remediation is to trace the finding to the control that failed and the team that can change it safely. A DAST tool may report an exposed application path, but that output is only the starting point. Security teams should classify the issue using evidence from the request path, headers, authentication flow, WAF or gateway logs, and any linked secrets or tokens. That classification tells you whether the remediation belongs in code, infrastructure, identity policy, or a compensating control.

• If the path should never exist, the application team usually removes or hardens the route.
• If the path exists but should require stronger authentication, IAM or the application team may need to tighten authorization logic.
• If the exposure is created by a misconfigured gateway, ingress rule, or reverse proxy, the platform or cloud team owns the change.
• If the path reveals secrets, token scopes, or session data, AppSec and the application owner should coordinate immediate containment and rotation.

For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the work in AC, SC, and CM families, which is often a better operational model than “scan owner equals fix owner.” In mature environments, the ticket should record the failed control, the service owner, the validating evidence, and the rollback plan. That makes handoff cleaner and prevents remediation from stalling while teams debate where the scanner was deployed. It also supports better triage in SIEM or SOAR workflows when the same path appears across multiple services. These controls tend to break down when service ownership is fragmented across shared platforms, because no single team has end-to-end authority to change the exposed path.

Common Variations and Edge Cases

Tighter ownership models often increase coordination overhead, requiring organisations to balance speed of remediation against precise accountability. That tradeoff becomes visible when a single DAST finding implicates multiple stacks or shared controls.

There is no universal standard for this yet, but best practice is evolving toward control-based ownership with a named technical lead for remediation. In microservices and API-heavy environments, one exposed path may originate in application code, be published by API management, and be reachable only because an ingress policy is too broad. In that case, the application team may own the fix, while the platform team adjusts exposure boundaries and AppSec validates the final state.

Edge cases also arise when the path is “exposed” by design, such as a public health check, login endpoint, or documentation route. Here the issue is not exposure itself, but whether the route is protected appropriately and whether sensitive functions are reachable without the expected control. For agentic or AI-enabled systems, exposed paths can become a tool-access problem if an agent can invoke internal endpoints without strong authorization. That is where identity and access governance intersects directly with web attack surface management. Where the path is public by requirement, the remediation objective shifts from removal to hardening, monitoring, and explicit approval of the exposure boundary. A reliable ownership model should therefore define who fixes the defect, who validates the control, and who signs off that the residual risk is acceptable.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• Why do application testing tools matter for NHI governance?
• How do organisations reduce the dwell time of exposed credentials at scale?
• Who should own remediation when an NHI finding affects production services?