DEV Community

turingrtss
turingrtss

Posted on Edited on

I Claimed 12 Critical Security Bugs. Most Were False Positives. Here's What I Learned.

#ai #security #python #opensource

Update (Sept 4): After manual verification of every finding, I'm correcting this article. The original version claimed 12 critical vulnerabilities. On deeper review, most were false positives from my regex-based scanner. The scanner flags patterns without understanding context — whether variables come from user input or internal config, whether sanitization exists nearby, whether the pattern is intentional by design. I'm leaving the technical analysis below but with honest verdicts. This is a lesson in verifying scanner output before publishing.

What Happened

I built AIVerify, a regex-based SAST scanner, and ran it against popular GitHub repos. The scanner flagged patterns like f-strings in SQL queries and subprocess calls with shell=True. I published the results without manually verifying each finding against the actual source code context.

That was a mistake.

What the Scanner Actually Found (Verified)

After cloning every repo and reading the code around each flagged line:

0 confirmed exploitable vulnerabilities. 1 questionable. 11 false positives.

Why They Were False Positives

Pattern: f-string SQL — The scanner flags f"SELECT * FROM {table}". But in most cases, table comes from internal config (dbt model names, application constants), not user input. One repo (inspect_ai) actually had explicit SQL injection protection that my scanner ignored.

Pattern: subprocess with shell=True — The scanner flags any subprocess call with string formatting. But many of these are admin scripts using environment variables, sandboxed execution environments with uid isolation, or CLI tools with no web-facing surface.

Pattern: requests.get(url) — Flagged as SSRF, but the URL came from AI API responses, not user input. Low practical risk.

What I Learned

  1. A scanner finding is a lead, not a verdict. Every finding needs manual verification before disclosure.
  2. Context matters more than pattern. The same code pattern is dangerous in a web handler and harmless in a config script.
  3. Verify before you publish. I sent disclosure emails to 8 maintainers about non-issues. I published articles claiming findings that don't hold up.
  4. Regex SAST has hard limits. Without data flow analysis, you can't distinguish user input from internal variables.

AIVerify v0.4.0

I've tightened the scanner rules based on this experience:

  • Command injection now requires shell=True with dynamic input (was flagging list-based subprocess)
  • XXE now requires untrusted input source (was flagging all XML parsing)
  • SSRF now requires user input indicators
  • Skips test/docs/examples directories by default

The false positive rate dropped significantly. But the fundamental limit remains: regex can't trace data flow.

GitHub: https://github.com/turingrtss/aiverify

The Real Takeaway

Don't trust scanner output blindly. Not from my tool, not from any tool. Every finding is a hypothesis that needs verification. I failed to do that verification before going public, and I'm correcting it now.

This correction was published because honesty matters more than marketing. The original claims were wrong and I owe that transparency to anyone who read them.

Top comments (0)