Too noisy means your linter flags eval() everywhere, including the one in a test file parsing a hardcoded string that will never see user input. Too shallow means it misses the SQL injection that's three variable assignments away from req.body because it only pattern-matches on surface-level code.

I wanted to build something that actually reasons about code the way a security auditor does — following data through the program, understanding context, and only flagging things that are genuinely dangerous. The result is AuraWatch, a VS Code extension launching May 15th, 2026.

This is the story of how I built it and what the architecture looks like.

Starting With the Right Foundation: Lossless Semantic Trees

The first decision was the analysis foundation. Most linters use a regular Abstract Syntax Tree (AST). The problem with a standard AST is that it strips information — whitespace, comments, formatting — which is fine for analysis but breaks things when you want to write code back to disk after applying a fix.

I chose Lossless Semantic Trees instead. An LST preserves every token in the source file. When a transformer modifies a node and regenerates the code, the output is byte-for-byte identical to the input except for the specific change that was made. No reformatting, no lost comments, no surprise diffs.

For JavaScript and TypeScript I use ts-morph, which wraps the TypeScript compiler API and gives full type-aware LST access. For Python I use LibCST, which was specifically designed for lossless transformations.

This foundation powers both the analysis (reading the tree) and the auto-fixing (rewriting the tree).

The Part Most Tools Skip: Taint Analysis

Here's the vulnerability that motivated me to go beyond simple rule matching:

app.post('/users', async (req, res) => {
    const { username } = req.body;
    const sanitized    = username.replace(/'/g, '');  // developer thinks this is safe
    const user         = await db.query(`SELECT * FROM users WHERE name = '${sanitized}'`);
    res.json(user);
});

A linter that pattern-matches on template literals inside query() will catch this. But what about:

async function getUser(name) {
    return db.query(`SELECT * FROM users WHERE name = '${name}'`);
}

app.post('/users', async (req, res) => {
    const result = await getUser(req.body.username);
    res.json(result);
});

Now the tainted data crosses a function boundary. The query function looks perfectly safe in isolation. The route handler looks fine too — it's just passing a string to a function. But together they form a SQL injection vulnerability.

AuraWatch's taint engine handles this with three passes:

Pass 1 — Source identification. Every access to req.body, req.query, req.params, req.headers, and similar HTTP inputs is marked as a taint source. Destructured variables get marked too: const { username, password } = req.body marks both username and password as tainted.

Pass 2 — Propagation. Any variable assigned from a tainted variable becomes tainted. This propagates through assignments, function arguments, and return values.

Pass 3 — Sink checking. Known dangerous functions are checked against their arguments. If any argument contains a tainted variable, the vulnerability is flagged — along with the name of the specific variable that carried the taint and where it originated.

The sinks currently tracked include:

eval()          → CWE-95  Code Injection
exec()          → CWE-78  OS Command Injection
db.query()      → CWE-89  SQL Injection
fs.readFile()   → CWE-22  Path Traversal
res.redirect()  → CWE-601 Open Redirect
innerHTML       → CWE-79  XSS
res.render()    → CWE-94  Template Injection

The Unexpected Addition: SMT Solving

I didn't originally plan to include an SMT solver. It came out of a specific bug I kept seeing in code reviews — integer range errors that cause crashes in production but are completely invisible to linting.

SMT (Satisfiability Modulo Theories) is a form of formal verification that checks whether a mathematical formula can be satisfied. In plain terms: given what we know about a variable's constraints, can it ever equal zero? Can this branch ever execute?

For Python, I integrate the Z3 SMT solver directly. Z3 is a theorem prover from Microsoft Research that's used in academic formal verification. AuraWatch uses it to prove things like:

def process(items, page_size):
    if page_size > 0:
        return items[:page_size]
    return items[0] / page_size  # Z3 proves page_size can be 0 here

For JavaScript, I built a lightweight interval arithmetic solver that runs in-process without native dependencies. It maintains a range map — tracking the minimum and maximum possible value of each variable given the conditional guards seen so far:

function allocate(size) {
    // No guard on size — solver knows size ∈ (-∞, +∞)
    // Can be zero or negative
    return new Array(size).fill(0); // flagged: size can be ≤ 0
}

function allocateSafe(size) {
    if (size <= 0) throw new Error('Invalid size');
    // Now solver knows size ∈ (0, +∞)
    return new Array(size).fill(0); // clean
}

The solver also detects contradictory conditions — branches that can never execute because their conditions are mutually exclusive — and always-true conditions that bypass auth guards:

if (isAdmin || true) {
    // SMT proves this always executes regardless of isAdmin
    deleteAllRecords();
}

Defending Against AI-Generated Code: Hallucination Detection

This one surprised me when I added it, but it's become one of the most useful findings in practice.

LLMs hallucinate package names. Not constantly, but often enough that it's a real problem. A model trained on GitHub data might confidently suggest require('express-validator-plus') or require('mongoose-utils') — packages that sound plausible but don't exist on npm.

This matters for security because of how npm's postinstall hook works. If a package doesn't exist and an attacker registers it later, anyone who npm installs it gets arbitrary code execution on their machine during installation. This is exactly how several high-profile supply chain attacks have worked.

AuraWatch maintains a registry of ~200 well-known legitimate packages and checks every require() and import against it. It also runs typosquatting detection against known confusable patterns:

lodas    → lodash      (missing h)
expres   → express     (missing s)
mongoos  → mongoose    (missing e)
axio     → axios       (missing s)

A hallucinated or suspicious package gets flagged as CRITICAL — not because the code is necessarily broken today, but because a future supply chain attack could make it dangerous retroactively.

Framework-Aware Analysis

Generic AST rules miss framework-specific patterns. A React developer using dangerouslySetInnerHTML needs different guidance than an Express developer calling res.render(). AuraWatch auto-detects the framework from import statements and applies the relevant sink rules.

React: dangerouslySetInnerHTML without DOMPurify.sanitize() is flagged as XSS. The auto-fixer wraps the value with DOMPurify.sanitize() and adds the import if it's missing.

Express: Dynamic res.render() arguments (template name from user input) flag as Server-Side Template Injection. Dynamic res.redirect() flags as Open Redirect.

Next.js: context.query values spread into page props in getServerSideProps without validation are flagged — a common pattern in generated Next.js code that introduces reflected XSS.

Fastify: reply.send(request.body) echoing raw request bodies in responses flags as potential XSS when the response is rendered in a browser.

Auto-Fixing: The Hard Part

Analysis is the easier half. Writing fixes that are correct, safe, and preserve the original code formatting is genuinely hard.

Every auto-fixer in AuraWatch is a CST Transformer — a visitor that walks the lossless syntax tree and replaces specific nodes. The key constraint is that the transformer must only touch the node it's fixing. Everything else — adjacent code, comments, indentation, blank lines — must come out identical.

Some examples of what the fixers do:

Hardcoded secrets:

// Before
const api_key = 'sk-prod-abc123';

// After
const api_key = process.env.API_KEY || "";

Weak PRNG in security context:

// Before
const token = Math.random().toString(36);

// After
const token = require("crypto").randomBytes(4).readUInt32BE(0).toString(36);

Unsafe YAML loading (Python):

# Before
config = yaml.load(data)

# After
config = yaml.safe_load(data)

All fixes go through VS Code's native diff viewer before anything touches disk. The user sees exactly what changed and explicitly accepts or rejects it. AuraWatch never writes to a file without confirmation.

The Deployment Architecture

AuraWatch runs as two independent microservices on Google Cloud Run:

Python Engine handles .py files. It runs LibCST for lossless tree analysis, Z3 for SMT solving, and exposes a FastAPI endpoint that the VS Code extension calls.

JS/TS Engine handles .js, .ts, .jsx, and .tsx files. It runs ts-morph for TypeScript-aware analysis, the custom interval arithmetic SMT solver, and exposes a Fastify endpoint.

The VS Code extension routes each scan to the correct engine automatically based on the active file's language ID. Authentication uses magic links — the user enters their email, receives a time-limited link, clicks it, and VS Code catches the redirect via a URI handler and stores the API key in the OS keychain via VS Code's SecretStorage API. No passwords, no OAuth dance, no API key pasted into a settings file.

Billing runs through Stripe with a Firestore backend. Free tier is 25 scans per month. Pro is unlimited.

What's on the Roadmap

A few things I'm building toward after launch:

GitHub Actions integration. The analysis engines are already HTTP APIs — wiring them into a CI workflow is straightforward. The goal is to block PRs that introduce new critical vulnerabilities.

Inline diagnostics. Right now findings appear in the chat panel. The next step is surfacing them as editor squiggles with hover cards, the same way TypeScript type errors appear.

Cross-function taint tracking. The current taint engine handles taint within a single function scope. Following data across function calls and module imports requires building a call graph first — that's the next major analysis milestone.

Java and Go support. Both languages have mature CST libraries. The architecture is engine-agnostic so adding a new language is mostly writing the analyzer rules.

Launch

AuraWatch launches on the VS Code Marketplace on May 15th, 2026.

If you're a security engineer, developer, or just someone who's been burned by a vulnerability that a smarter tool should have caught — follow along on Twitter/X and LinkedIn. And if you want to give early feedback before launch, reach out directly. I'm actively building this and I take every piece of feedback seriously.