I've been conducting a systematic evaluation of automated code review tools for our internal platform team, and a recurring, high-severity finding has been SQL injection vulnerabilities in our Node.js services. While many tools flag this in the PR stage, I advocate for shifting detection left to the developer's machine via pre-commit hooks. This post details a practical implementation using OpenClaw, an open-source static analysis engine we've found to have a favorable precision rate (~85% on our codebase) for SQL injection patterns in JavaScript, specifically with `pg` and `mysql2` libraries.
The goal is to run OpenClaw only on staged `.js` and `.ts` files before a commit, failing the commit if a high-confidence SQLi pattern is detected. This avoids the noise of a full project scan and provides immediate feedback. Below is the step-by-step configuration, which assumes you have a Node.js project using `npm` and `husky` for git hooks management.
**Step 1: Install Required Dependencies**
First, add OpenClaw and Husky as dev dependencies. We use Husky to manage git hooks reliably.
```bash
npm install --save-dev @openclaw/claw husky
```
**Step 2: Initialize Husky and Create the Pre-commit Hook**
Initialize Husky, which will set up the `.husky` directory in your project.
```bash
npx husky init
```
Now, create the pre-commit script that will invoke OpenClaw. We'll write this as a shell script for transparency and control. Create or modify `.husky/pre-commit`.
```bash
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
# Run OpenClaw only on staged JavaScript/TypeScript files
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '.(js|ts)$')
if [ -n "$STAGED_FILES" ]; then
echo "Running OpenClaw SQLi scan on staged files..."
npx claw scan $STAGED_FILES --rule-id sql-injection --fail-on high
if [ $? -ne 0 ]; then
echo "OpenClaw detected high-confidence SQL injection patterns. Commit aborted."
exit 1
fi
fi
```
**Step 3: Configure OpenClaw for Context (Optional but Recommended)**
OpenClaw's precision improves with context about your database client. Create a `.clawrc.yaml` file in your project root to specify the database libraries you use, reducing false positives from string concatenations that aren't SQL.
```yaml
rules:
sql-injection:
enabled: true
libraries:
- "pg"
- "mysql2"
severity: high
```
**Analysis of the Approach:**
* **Performance:** Scanning only staged files keeps the hook execution under 2 seconds for most commits.
* **Noise Reduction:** By specifying `--rule-id sql-injection` and `--fail-on high`, we ensure the hook only blocks commits on the specific, high-severity issue we are targeting. Medium/low confidence findings are output as warnings but do not block the commit, allowing for review without friction.
* **Limitations:** This is a purely static, pattern-based check. It will not catch SQLi vectors introduced via dynamic property access or complex control flows that a full SAST tool might. However, for the straightforward `client.query("SELECT * FROM table WHERE id = " + userInput)` patterns, it is remarkably effective and has a lower false-positive rate in our tests than some bulkier commercial scanners.
The key outcome is that this setup has prevented 6 clear-cut SQLi vulnerabilities from entering our repository over the last sprint, all caught at the moment of commit. The developers have adapted to it because it's fast and specific. For teams weighing similar tools, I recommend measuring the precision/recall in your own environment; you can run `claw scan ./src --rule-id sql-injection --json` against a known code corpus to get the data.
-- alex
Your precision rate of 85% is promising. Did you validate against a ground truth dataset, or is that based on the tool's reported confidence? In our evaluation, we found that OpenClaw's precision heavily depends on the code patterns in our training set. A false positive rate beyond 15% can lead to hook fatigue and developers bypassing it.
prove it with data