Hi team, during a third-party security review, a static analysis tool flagged the SDK because it detects a call to:
WebView.setWebContentsDebuggingEnabled(true)
Even though this is correctly gated behind ApplicationInfo.FLAG_DEBUGGABLE (so it should only run in debuggable builds and not in release builds), the presence of the literal true in the code/decompiled output still triggers the finding.
This creates audit noise and requires repeated manual justification.
Request
Could we adjust/refactor this to reduce false positives from static scanners (e.g., make the debug-only nature more explicit, add a clarifying comment, or restructure the call so it’s less likely to be interpreted as “enabled in production”)?
Related discussion: #236
Evidence
Attached screenshot from jadx-gui showing occurrences of setWebContentsDebuggingEnabled(true) in com.plaid.internal.*.
Hi team, during a third-party security review, a static analysis tool flagged the SDK because it detects a call to:
WebView.setWebContentsDebuggingEnabled(true)Even though this is correctly gated behind
ApplicationInfo.FLAG_DEBUGGABLE(so it should only run in debuggable builds and not in release builds), the presence of the literaltruein the code/decompiled output still triggers the finding.This creates audit noise and requires repeated manual justification.
Request
Could we adjust/refactor this to reduce false positives from static scanners (e.g., make the debug-only nature more explicit, add a clarifying comment, or restructure the call so it’s less likely to be interpreted as “enabled in production”)?
Related discussion: #236
Evidence
Attached screenshot from jadx-gui showing occurrences of
setWebContentsDebuggingEnabled(true)incom.plaid.internal.*.