Who is accountable for DAST findings when security scans are run in CI/CD pipelines?

Why This Matters for Security Teams

DAST findings in CI/CD pipelines are only useful when there is a named owner who can act on them. If findings are routed into a generic security backlog, remediation slows, risk acceptance becomes informal, and build pipelines start to lose credibility with engineering teams. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with the broader expectation that security controls must be assigned, monitored, and enforced, not merely reported.

The practical question is not whether security should care about the findings. It is who can make the fix, who can accept the risk, and who can prevent release when a critical issue is still open. In mature delivery pipelines, that accountability usually sits with the application or API team, with security defining policy and escalation thresholds. In practice, many security teams encounter DAST only after a release failure, customer issue, or audit exception has already exposed the lack of clear ownership, rather than through intentional triage governance.

How It Works in Practice

Effective accountability starts with the code owner, because the team that builds and deploys the application has the context needed to interpret a DAST result. Security teams should define the rules of engagement, not act as the permanent remediation desk. That means setting severity thresholds, false-positive review steps, SLAs for fix or exception, and escalation paths when a finding blocks release.

In a well-run pipeline, DAST findings should flow into the same engineering workflow used for other defects. The scanner produces evidence, the application owner validates impact, and the team records remediation or risk acceptance in the ticketing system. Security then monitors control performance, trends, and repeated failure patterns. This approach is consistent with the control intent in NIST guidance and with operational practices described in OWASP Testing Guide, which treats dynamic testing as a defect discovery and verification activity rather than a standalone compliance event.

• Assign each application, API, or service to a named engineering owner before scans run.
• Route findings into the same backlog, board, or incident process the delivery team already uses.
• Use severity-based gates so critical issues can block release while lower-risk items are tracked.
• Require security approval only for exceptions, disputed findings, or policy overrides.
• Measure repeat findings to spot ownership gaps, weak testing, or recurring unsafe patterns.

For organisations building stronger release controls, the pipeline should also reflect secure-by-design expectations from NIST Secure Software Development Framework and be cross-checked against the attack paths in MITRE ATT&CK where DAST findings map to exploitable behaviours. These controls tend to break down when multiple squads share one deployment pipeline because ownership becomes ambiguous and no single team can reliably remediate the flaw.

Common Variations and Edge Cases

Tighter release gating often increases developer friction and triage workload, requiring organisations to balance faster delivery against stronger control over risky code. That tradeoff becomes more visible when DAST is run on every merge request, on every nightly build, or across many microservices at once.

There is no universal standard for whether security, platform engineering, or application teams should approve every exception. Current guidance suggests the most sustainable model is shared accountability: security defines policy and oversight, platform engineering maintains the scanning pipeline, and the product team owns the outcome. This separation is especially important when scans produce noisy results, because blind trust in scanner output can create alert fatigue and weaken engagement.

Edge cases include third-party APIs, shared service accounts, and ephemeral test environments. If the finding relates to vendor-managed code, the accountable party may be the internal service owner who integrated the dependency, even if a supplier must make the actual fix. In regulated environments, unresolved findings may also affect release approval under secure software supply chain guidance and broader governance expectations in NIST SP 800-207 Zero Trust Architecture. The model gets harder when organisations centralise scanning but decentralise delivery, because responsibility and authority are no longer aligned.

Related resources from NHI Mgmt Group

• How should security teams implement DAST in CI/CD pipelines?
• How should security teams govern credentials used by CI/CD pipelines?
• How should security teams handle protobuf vulnerabilities in CI/CD pipelines?
• How should security teams enforce MIT license compliance in CI/CD pipelines?