Who is accountable for deciding whether a vulnerability is exploitable when SAST and DAST findings disagree?

Accountability should sit with the AppSec function, working with development owners, because the decision requires both code context and runtime validation. Security teams need a repeatable triage process that resolves disagreement between tools, documents the rationale, and ties the final priority to exploitability, business impact, and remediation readiness.

Why This Matters for Security Teams

When SAST and DAST disagree, the real problem is not the tool mismatch itself, but the lack of a clear accountability model for deciding whether the issue is exploitable in the target environment. AppSec is usually the right decision owner because it can interpret code paths, attack preconditions, and compensating controls, while development owners can confirm design intent and deployment context. That separation matters when findings affect release timing, remediation priority, and risk acceptance. Guidance from CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the need for repeatable vulnerability management and accountability, not ad hoc judgment.

Practitioners often get this wrong by treating tool output as the final authority. SAST may flag theoretically reachable code that is not exposed in production, while DAST may miss a weakness behind authentication, feature flags, or environment-specific logic. The accountable team must decide whether the finding is exploitable now, exploitable under realistic conditions, or not exploitable at all, then record why. In practice, many security teams encounter exploitability disputes only after release pressure has already turned triage into a production-risk argument rather than a technical review.

How It Works in Practice

A workable process starts with a triage owner, usually AppSec, who coordinates input from development, product, and operations. The goal is to resolve disagreement through evidence, not preference. SAST can identify vulnerable code paths, insecure APIs, and dangerous patterns in source. DAST can test deployed behavior, authentication boundaries, request handling, and observable exposure. Neither tool alone can determine exploitability with full confidence.

A strong triage workflow usually includes:

• Confirming whether the vulnerable code is present in the deployed build.
• Checking whether the path is reachable from an untrusted boundary.
• Validating preconditions such as authentication, privileges, feature flags, or network segmentation.
• Reviewing whether compensating controls reduce the likelihood or impact of exploitation.
• Recording the final disposition, owner, and remediation deadline in the vulnerability system.

This is where security policy and operational evidence need to meet. AppSec should apply a repeatable rubric for exploitability, while developers provide code-level clarification and platform teams validate runtime configuration. If the organisation uses security control baselines, NIST SP 800-53 Rev 5 Security and Privacy Controls supports documenting assessment and remediation expectations, and CISA cyber threat advisories can help calibrate whether a weakness maps to active exploitation patterns. The outcome should be a decision that ties exploitability to business impact, not just CVSS severity.

These controls tend to break down when application ownership is split across multiple product teams and no single function can validate code changes, deployment state, and compensating controls in one review.

Common Variations and Edge Cases

Tighter exploitability review often increases triage overhead, requiring organisations to balance faster release flow against higher decision quality. That tradeoff becomes visible in high-change environments, where automated scanning produces large volumes of findings and manual validation can become a bottleneck.

There is no universal standard for this yet, but current guidance suggests that accountability should remain with AppSec even when engineering teams supply the technical evidence. In regulated or audit-heavy environments, the final decision may also involve risk owners or security leadership for formal acceptance, especially when remediation is deferred. For cloud-native systems, environment drift can make a SAST finding appear severe while runtime controls make exploitation unlikely, or vice versa. ENISA Threat Landscape is useful context when deciding whether a disputed issue aligns with active attacker techniques.

The most important edge case is when DAST cannot reach the vulnerable function because of authentication, client-side routing, or internal-only exposure. That does not automatically make the issue safe. The better question is whether a realistic attacker path exists through another entry point, a misconfiguration, or an adjacent trust boundary. In those cases, the accountable team should treat the finding as unresolved until code review, runtime testing, or architecture analysis closes the gap.

Related resources from NHI Mgmt Group

• Who is accountable when Oracle and an external governance layer disagree on SoD findings?
• Who is accountable when an accepted vulnerability exception later becomes exploitable through AI?
• Who is accountable when a patched vulnerability remains exploitable across the fleet?
• Who is accountable when a vulnerability report misses an exploitable issue?