TheAuditorTool

Hi HN, OP here.

I’m a former Enterprise Systems Architect (Cisco/VMware) turned "vibe coder." I realized quickly that AI coding is dangerous because LLMs lack *context* and *verification*. They hallucinate because they are guessing at the file structure.

So, out of pure spite for flaky tools, I built *TheAuditor*.

*The Concept:* Instead of grepping files, I index the entire repo (Python, TS, Go, Rust, Terraform, CDK) into a local SQLite database (~180MB for a mid-sized repo). Because the code is in a DB, I can query the call graph like SQL.

*The Tech (The "Hard" Part):* I needed a way to trace data flow through the infrastructure to prevent the AI from introducing vulnerabilities. I ended up building a *Hybrid Taint Engine* that extends the Oracle Labs (2021) IFDS research: 1. *Forward Flow:* Traces entry points to reachable sinks to prune the graph. 2. *Backward IFDS:* Runs a precise "Interprocedural Finite Distributive Subset" analysis on the pruned graph. 3. *The Handshake:* We only report vulnerabilities where both engines intersect.

*The "Systems Architect" approach:* Coming from a background in critical infrastructure, I hate silent failures. I implemented a *5-Layer Fidelity System*. Every parser emits a cryptographic manifest. If the DB storage receipt doesn't match the manifest (transaction mismatch or data loss), the tool hard-crashes. I'd rather a stack trace than a false negative.

*Why I built it:* I use this as a "Flight Computer" for my AI agent. * Before refactoring, it runs `aud impact` to calculate the blast radius. * Before writing code, it runs `aud explain` to get a token-optimized context bundle of definitions.

This is v2 (a complete rewrite after 800 commits). I learned a lot since my first attempt. The code is open source (AGPL).

Happy to answer questions about the SQLite schema or the IFDS implementation.

Yeh, i dont dont use nix so when asked to follow the link? It didnt work as it should. And because i dont use nix? Hard to catch it until my friend did...

That said? Did you the hash fail? Yes it did, security working as intended... Anything more to add? :)

No? At least read couple lines in the readme before joining the discussion please.

Yes, i cant code but i can build systems, more news at eleven... That's why I built this.

The 204 SQL injections it found in production? Those were real. Those are produced by industry standard tools....

The nightmare isn't that I used AI to build a security tool. The nightmare is that your production code was probably written the same way.

At least I'm checking mine.

AST parsing fails primarily due to installation issues, not syntax errors in your code.

TheAuditor uses a sandboxed environment (.auditor_venv/) to avoid polluting your system. When Tree-sitter isn't properly installed in that sandbox, we fall back to regex patterns. Common causes:

1. Missing C compiler - Tree-sitter needs to compile language grammars 2. Incomplete setup - User didn't run aud setup-claude --target . which installs the AST tools 3. Old installation - Before we fixed the [ast] dependency inclusion

If your code had syntax errors, you'd get different errors entirely (and your code probably wouldn't run). The "AST parsing fails" message specifically means Tree-sitter isn't available, so we're using the fallback regex patterns instead.

Just pushed clearer docs about this today actually. Run aud setup-claude --target . in your project and Tree-sitter should work properly.

You're absolutely wrong. - lol.

Why does it matter? Just because you know how to code doesnt mean you know how to build systems, architecture or infrastructure? I do, professional background in it.

The glaring thing most people seem to miss that llm generated code is like TOS and unless you work in a more enterprise team setting? You are not going to catch 90% of the issues...

If this was used before releasing the tea spill fiasco, only to name one? It would never have been a fiasco. Just saying..

"Using SonarQube is probably the way to go" "We don't need specialized tools"

Pick one.

SonarQube IS a specialized tool. It just specializes in different things than TheAuditor.

SonarQube: "This file has issues" heAuditor: "Your frontend and backend disagree about the data model"

Both have their place.

You're absolutely right to be skeptical! You do ignore that vibe coding isnt going away...

That's exactly why I built TheAuditor - because I DON'T trust the code I had AI write. When you can't verify code yourself, you need something that reports ground truth.

The beautiful irony: I used AI to build a tool that finds vulnerabilities in AI-generated code. It already found 204 SQL injections in one user's production betting site - all from following AI suggestions.

If someone with no coding ability can use AI + TheAuditor to build TheAuditor itself (and have it actually work), that validates the entire premise: AI can write code, but you NEED automated verification.

What could go wrong? Without tools like this, everything. That's the point.

Do you care about the messenger or the message?

I use AI to communicate because I have dyslexia and ADHD. It helps me articulate technical concepts clearly. The irony isn't lost on me - I built a tool to audit AI-generated code, using AI, because I can't code, and now I'm using AI to explain it.

If that offends you more than 204 SQL injections in production code, we have different priorities.

After reviewing my own code. Thanks for digging into the code! You're reviewing the regex fallback patterns that only trigger when AST parsing fails. The primary detection uses Tree-sitter for structural analysis and taint flow tracking.

That TOCTOU pattern IS terrible - it's meant as a last-resort 'something might be wrong here' flag when we can't parse the AST. The real detection happens in theauditor/taint_analyzer/ which tracks actual data flow from filesystem checks to file operations.

But you're right - even fallback patterns shouldn't be this noisy. I'll tighten it to only flag actual filesystem operations: - os.path.exists → open() - fs.exists → fs.writeFile() - File.exists() → new FileWriter()

  If you actually run the tool with aud full, it uses the proper AST analysis first. These regex patterns are
  the third fallback when Tree-sitter isn't available.

  Thanks for the specific feedback - this is exactly why I open-sourced it!

@quibono: Great questions! The "don't create venv" warning is because TheAuditor creates its own sandboxed environment (.auditor_venv/) for analyzing YOUR project. If you install TheAuditor inside your project's venv, you get nested virtualenvs which breaks the sandbox isolation. TheAuditor should be installed globally (or in ~/tools/), then it creates isolated environments for each project it analyzes.

The ESLint/Ruff/MyPy integration isn't about putting an LLM between you and linters. It's about aggregation and correlation. Example: - Ruff says "unused import" - MyPy says "type mismatch" - TheAuditor correlates: "You removed the import but forgot to update 3 type hints that depended on it"

The LLM reads the aggregated report to understand the full picture across all tools, not just individual warnings.

@ffsm8: You're absolutely right - I can't code and the dependency tree is probably a mess! That's exactly WHY I built this. When you're using AI to write code and can't verify if it's correct, you need something that reports the ground truth.

The irony isn't lost on me: I used Claude to build a tool that audits code written by Claude. It's enablement all the way down! But that's also the proof it works - if someone who can't code can use AI + TheAuditor to build TheAuditor itself, the development loop is validated.

The architectural decisions might be weird, but they're born from necessity, not incompetence. Happy to explain any specific weirdness!

You're absolutely right about that TOCTOU pattern - it's terrible! That regex would flag every if cache.has(key) then cache.add(key, value) as a race condition. Thank you for the specific example.

This perfectly illustrates why I need community input. I'm not a developer - I literally can't code. I built this entire tool using Claude over 250 hours because I needed something to audit the code that Claude was writing for me. It's turtles all the way down!

The "14 phases" you mentioned are in theauditor/pipelines.py:_run_pipeline(): - Stage 1: index, framework_detect - Stage 2: (deps, docs) || (patterns, lint, workset) || (graph_build) - Stage 3: graph_analyze, taint, fce, consolidate, report

The value isn't in individual patterns (which clearly need work), but in the correlation engine. Example: when you refactor Product.price to ProductVariant.price, it tracks that change across your entire stack - finding frontend components, API calls, and database queries still using the old structure. SemGrep can't do this because it analyzes files in isolation.

You're 100% correct that I oversold it with "solves ALL your problems" - that's my non-developer enthusiasm talking. What it actually does: provides a ground truth about inconsistencies in your codebase that AI assistants can then fix. It's not a security silver bullet, it's a consistency checker.

The bad patterns like that TOCTOU check need fixing or removing. Would you be interested in helping improve them? Someone with your eye for detail would make this tool actually useful instead of security theater.