Unpopular opinion: Most 'critical' SAST findings in dynamic languages are false.

I've been mapping data flows and evaluating API security postures for long enough to have developed a strong, data-backed skepticism regarding SAST tool output for dynamically-typed languages like Python, JavaScript, and Ruby. While SAST is indispensable for compiled languages with static types, its application in dynamic ecosystems often generates more noise than signal, particularly for the highest-severity findings.

The core issue lies in the inherent limitations of static analysis when faced with dynamic language features. To accurately track tainted data from source to sink, the tool must correctly resolve variable types, method definitions, and object shapes—tasks that are often impossible without executing the code. This leads to a proliferation of worst-case assumptions flagged as "critical" or "high" severity vulnerabilities that would be provably unreachable in a real execution context.

Consider a typical Python SAST finding flagged as "Critical: SQL Injection." The tool sees a string concatenation pattern leading to a database cursor execution.

```python
# Example triggering a common critical finding
def get_user_data(user_id, conn):
query = "SELECT * FROM users WHERE id = " + user_id # SAST alarm triggers here
result = conn.execute(query)
return result.fetchall()
```

A human reviewer (or a dynamic test) would immediately ask: What is the calling context of `get_user_data`? If `user_id` is, in practice, always an integer converted from a validated session token earlier in the workflow, the finding is a false positive. The SAST tool lacks the context to know this, so it must assume `user_id` is user-controllable and unsanitized. This pattern scales to thousands of lines, creating an overwhelming backlog of "critical" issues that dev teams must triage, eroding trust in the security tooling.

The problem is exacerbated by:
* **Metaprogramming and dynamic dispatch:** Common in Ruby and JavaScript frameworks, where method definitions and property access are determined at runtime.
* **Duck typing:** The inability to statically guarantee an object's available methods makes data flow analysis imprecise.
* **Heavy use of third-party frameworks and ORMs:** SAST tools struggle to model the internal behavior of libraries like Django ORM or Sequelize, often flagging safe ORM methods as potential injections.
* **Monorepo complexities:** Inter-project dependencies and shared libraries create analysis boundaries that are frequently mishandled, leading to both false positives and false negatives.

My proposed mitigation strategy involves a shift in workflow:
1. **Triage automation:** Integrate SAST findings directly into the CI/CD pipeline with automated, context-aware filtering. Findings on internal, non-user-facing API routes should be de-prioritized automatically.
2. **Precision tuning:** Aggressively customize rule sets to disable categories of findings known to be high-false-positive for your specific tech stack (e.g., "SQL Injection in Django QuerySet.filter() calls").
3. **Shift-right correlation:** Correlate SAST results with dynamic findings (DAST) and runtime context (RASP) from staging/production to identify which static findings correspond to actually exploitable endpoints. This feedback loop is crucial for calibrating the tool.
4. **Severity recalibration:** Reclassify most SAST findings in dynamic languages as "Medium" or "Low" by default, reserving "Critical" only for patterns that are unequivocally unsafe (like `eval()` on unsanitized input). This reflects the probabilistic nature of the finding.

The goal shouldn't be to discard SAST for these languages—it still catches genuinely dangerous patterns and enforces security-aware coding standards. However, we must treat its high-severity output not as a list of urgent vulnerabilities, but as a set of hypotheses about potential weaknesses that require further, context-sensitive investigation.