DEV Community: CopperSunDev

Command Injection in AI-Generated Express.js: A Real Scan

CopperSunDev — Tue, 11 Aug 2026 22:53:17 +0000

AI coding assistants generate Express.js routes that work. They also generate routes where user input reaches execSync() without sanitization. Those two facts coexist in the same file.

Here's the scan of a five-route Express.js user API built from four AI prompts. The prompts were specific and reasonable: user lookup, username search, avatar upload with ImageMagick, and data export. The scanner returned three findings in the first pass. Here's what they were, why they appeared, and what the scan missed.

What BrassCoders Returns on an AI-Generated Express.js API

BrassCoders scanned the five-route Express.js user API and returned three findings: two on the hardcoded JWT secret on line 10 (flagged by the JS/TS scanner as HIGH and by SecretsScanner as MEDIUM), and one CRITICAL command injection flagged by Semgrep taint analysis on line 73. The scan ran offline in under two seconds with no data leaving the machine.

The raw YAML output for the three findings:

- id: js_ts_c01129e7
  severity: high
  file_path: src/users.js
  line_number: 10
  title: "JS/TS Security: hardcoded_password"
  description: "Potential hardcoded credential assigned to \"JWT_SECRET\""
  code_snippet: "const JWT_SECRET = '';"
  detected_by: JavaScriptTypeScriptScanner

- id: secret_secret_keyword_f72527467796_10
  severity: medium
  file_path: src/users.js
  line_number: 10
  title: "Possible Secret Keyword"
  detected_by: SecretsScanner

- id: semgrep-command_injection-67dfad9b34c1
  severity: critical
  file_path: src/users.js
  line_number: 73
  title: "Tainted dataflow: command injection"
  description: "Tainted HTTP request data reaches a shell execution sink."
  detected_by: SemgrepTaintScanner

The JS/TS scanner and SecretsScanner both flagged line 10 independently — two different detection mechanisms, same source line. The Semgrep taint scanner traced the request body field filename from the HTTP handler into the execSync() call on line 73. That's the CRITICAL finding.

The CRITICAL Finding: Command Injection via execSync

BrassCoders's Semgrep taint scanner flagged CRITICAL command injection at line 73 of src/users.js: user-controlled HTTP request data flowing into a shell execution sink. The code was generated from the prompt "Write an Express route to resize a user's uploaded avatar with ImageMagick":

router.post('/:id/avatar', (req, res) =&gt; {
  const { filename } = req.body;
  const outputFile = `/var/uploads/avatars/${req.params.id}_thumb.jpg`;

  // Resize image using ImageMagick convert
  const result = execSync(`convert /var/uploads/${filename} -resize 150x150 ${outputFile}`);

  return res.json({ thumbnail: outputFile });
});

filename comes from req.body — a field the caller controls. The string template passes it directly to execSync(), which runs the result through a shell. An attacker sending filename: "a.jpg; rm -rf /var/uploads" in the request body gets the semicolon interpreted as a command separator. The rm -rf runs as the server process user.

The ImageMagick use case is exactly where this pattern appears in AI-generated code: the model knows convert takes a filename argument, uses template literals for string assembly (the simplest approach), and produces code that works for legitimate filenames. The shell metacharacter path never appears in a test that sends valid image filenames.

Two fixes are available. The safer one avoids the shell entirely by passing an argument array to spawn():

const { spawn } = require('child_process');

router.post('/:id/avatar', (req, res) =&gt; {
  const { filename } = req.body;
  const inputPath = `/var/uploads/${filename}`;
  const outputFile = `/var/uploads/avatars/${req.params.id}_thumb.jpg`;

  // Argument array — no shell interpolation
  const proc = spawn('convert', [inputPath, '-resize', '150x150', outputFile]);

  proc.on('close', (code) =&gt; {
    if (code !== 0) return res.status(500).json({ error: 'Conversion failed' });
    return res.json({ thumbnail: outputFile });
  });
});

spawn() with an argument array doesn't invoke a shell — each argument is passed directly to the process. Shell metacharacters in filename are treated as literal characters, not syntax. The additional fix is input validation: reject filenames containing path separators or characters outside the expected character set before reaching the spawn call at all.

The HIGH Finding: Hardcoded JWT Signing Key

BrassCoders's JavaScript/TypeScript scanner flagged HIGH on line 10 via Babel AST analysis — a credential string assigned to a variable named after its security function. SecretsScanner independently flagged the same line via detect-secrets entropy analysis. Two detectors, one source line.

The code:

// JWT signing secret
const JWT_SECRET = 'my-super-secret-jwt-key-do-not-share';

The comment confirms the developer knew this was a credential. The AI generated a literal string because a literal string satisfies the prompt "write a signing key setup" in the simplest way. The string works during development. The problem is what happens when the file commits: the secret is now in version control, and git history doesn't forget it. Deleting the line on the next commit leaves the credential in every prior commit.

BrassCoders's YAML output notes that the credential value is redacted — '' appears in code_snippet rather than the actual string. The file path, line number, and variable name appear; the secret value doesn't leave the machine.

The fix is straightforward:

const JWT_SECRET = process.env.JWT_SECRET;
if (!JWT_SECRET) {
  throw new Error('JWT_SECRET environment variable is required');
}

The explicit throw on startup catches misconfigured deployments before they can serve requests with a null or undefined signing key. Without it, jwt.sign(payload, undefined) produces tokens that verify against any undefined key — a silent failure mode worse than the startup crash.

What the Scan Missed: SQL Injection via Template Literals

BrassCoders didn't flag the two SQL queries in the API. Both use template literal interpolation — the same pattern that generates CRITICAL SQL injection findings in Python:

// Line 35 — unflagged
const user = db.prepare(`SELECT id, username, email FROM users WHERE id = ${userId}`).get();

// Line 57 — unflagged
const results = db
  .prepare(`SELECT id, username, email FROM users WHERE username LIKE '%${username}%'`)
  .all();

BrassCoders's SQL taint rules are in its Python scanner set — Bandit B608 and Semgrep's brass.python.taint.sql-injection rule trace string interpolation into SQL queries in Python. The JavaScript Semgrep ruleset currently covers command injection; SQL template literal injection isn't in it. The two queries went unflagged in this scan.

This is a real coverage gap. The fix is the same regardless of whether the scanner catches it: use parameterized queries. better-sqlite3's prepared statement API takes placeholders:

// Parameterized — not injectable
const user = db.prepare('SELECT id, username, email FROM users WHERE id = ?').get(userId);

const results = db
  .prepare('SELECT id, username, email FROM users WHERE username LIKE ?')
  .all(`%${username}%`);

The ? placeholder form passes userId and username as bound parameters rather than interpolating them into the query string. The driver handles escaping; no manual sanitization is needed. This pattern is the authoritative fix for SQL injection regardless of what the scanner reports.

The scan caught what it could detect structurally. The SQL queries require a rule that doesn't yet exist in the JavaScript taint ruleset. Until it does, parameterized queries are the defensive default.

Adding BrassCoders to a Node.js Project

BrassCoders scans JavaScript and TypeScript source files alongside Python — the same pip install brasscoders && brasscoders scan . command covers both languages. The JS/TS scanner uses Babel AST analysis for credential patterns and Semgrep taint rules for injection vulnerabilities. No separate install, no separate invocation.

pip install brasscoders
brasscoders scan /path/to/express-project

The scan emits YAML to .brass/ai_instructions.yaml, structured for Claude Code or Cursor consumption. Each finding includes severity, detector, file path, line number, and (for JS/TS findings) a code snippet with the credential value redacted. Claude Code reads the file and source-verifies each finding against the source.

For CI integration:

# .github/workflows/brasscoders.yml
steps:
  - name: BrassCoders scan
    run: pip install brasscoders &amp;&amp; brasscoders scan .

The command exits non-zero if the scan produces CRITICAL findings above your configured threshold. The three findings from this scan — two on the JWT secret, one CRITICAL command injection — would fail the CI step before the code reaches review.

The SQL injection in JavaScript template literals remains a manual review item until the JavaScript SQL taint rules ship. The command injection and credential findings are caught by the current scanner. Both categories of bugs appear consistently in AI-generated Express.js code because both patterns satisfy the prompt and pass local tests.

pip install brasscoders
brasscoders scan .
# CRITICAL: command injection at src/users.js:73
# HIGH: hardcoded credential at src/users.js:10

AI Coding Tool Security Risk for Engineering Leaders

CopperSunDev — Tue, 11 Aug 2026 22:44:55 +0000

The research on AI-generated code security reaches engineering teams as anecdote before it reaches them as data. Here's the data.

Three independent studies from the last 24 months document a consistent pattern: AI coding assistants produce code that passes developer review at higher rates than it deserves, the security gap doesn't close as models get larger, and most engineering organizations have no formal process for managing the risk. All three problems have known solutions. The first step is understanding the actual scope.

What AI-Generated Code Security Research Shows

BrassCoders's N=15 AI-generated code corpus detected at least one security finding in all 15 files when scanned with the full 12-scanner stack — a controlled research sample, not a deployment-scale dataset. The corpus is published at coppersun.dev/benchmarks: 15 Python files generated from security-relevant prompts, with reproducible scan instructions. The external research operates at substantially larger scale and reaches similar conclusions.

Veracode's July 2025 GenAI Code Security Report tested over 100 large language models across 80 distinct security-relevant tasks. The headline number: 45% of AI-generated code samples fail security tests. Broken down by language, Java failed at 72%, C# at 45%, JavaScript at 43%, and Python at 38%. Cross-site scripting tests failed at 86% of relevant test cases across the tested models. The finding that matters most for engineering leaders: newer and larger models showed no consistent security improvement over earlier models. Scaling the model doesn't close the vulnerability gap.

Perry et al. (CCS 2023, 47 participants) ran a controlled experiment assigning developers either an AI coding assistant or no assistant. On an ECDSA signing task, 3% of the AI-assisted group produced secure code versus 21% of controls (p=0.039). The ECDSA task is a useful probe because correct implementation requires parameter choices subtle to non-cryptographers — the nonce k must be random and never reused, and an incorrect implementation looks structurally correct to reviewers who don't know that constraint. The study used codex-davinci-002, a 2022-era model; frontier models today produce more fluent code. Whether they've closed the cryptographic correctness gap is an open research question. Veracode's 2025 findings suggest the gap persists across model generations.

Checkmarx's Future of AppSec 2025 report (1,519 respondents, August 2025) measured the organizational response: 98% of organizations reported a security breach attributable to vulnerable code, and only 18% had governance policies in place for AI coding tools. Adoption is ahead of governance by 82 percentage points.

Why AI Assistants Produce Insecure Code

BrassCoders's N=15 corpus shows three bug categories recurring across the AI-generated files: SQL injection via format-string query assembly, hardcoded credentials in configuration and initialization code, and unsafe cryptographic calls. All three share the same structural origin — the AI generates code that satisfies the stated prompt and passes local tests, with no model of the production attack surface the code will face.

SQL injection through format-string assembly is the clearest case. A Flask database query generated from "write a user lookup by ID" produces:

cur.execute("SELECT id, name, email FROM users WHERE id = %s" % user_id)

This query returns correct rows during development. Tests pass. The vulnerability — SQL injection via user-controlled user_id — only manifests when an attacker sends a crafted string to the endpoint. Standard tests don't exercise that path unless the suite was written specifically to test injection resistance. BrassCoders flags this as CRITICAL via Bandit B608 and Semgrep taint analysis. The fix is parameterization:

cur.execute("SELECT id, name, email FROM users WHERE id = ?", (user_id,))

Hardcoded credentials follow the same pattern. A configuration module generated from "write an HMAC signing key setup" produces SECRET_KEY = "s3cr3t-signing-key-change-me". A literal string satisfies the prompt; it works during development; it commits to version control when the developer runs git add. BrassCoders's SecretsScanner flags it HIGH and redacts the credential value from YAML output — the code snippet and file path appear, but not the literal secret. The fix: SECRET_KEY = os.environ.get("HMAC_SECRET_KEY", "").

The cryptographic case requires more context-reading. hashlib.md5() without usedforsecurity=False triggers Bandit B324 because MD5 is broken for authentication and signing — collision attacks let an attacker substitute a different input that produces the same hash. For content deduplication (asking "are these bytes identical?"), collision attacks are irrelevant. The AI generates code correct for the stated use case. The scanner correctly flags the structural pattern. Whether the finding is a real vulnerability depends on what the digest is used for downstream. That's context the scanner can't read. The AI reviewer handles it.

The Overconfidence Problem

BrassCoders catches SQL injection, hardcoded credentials, and command injection patterns at commit time — before the code enters a review cycle where Perry et al.'s overconfidence finding becomes expensive. The study's core result was explicit: AI-assisted developers rated their code as more secure than controls rated theirs, while actually writing less secure code. The model's apparent confidence transfers to the developers reviewing its output.

This is a review-calibration problem, not a one-time training fix. Fluent, well-structured AI-generated code carries a lower friction signal than code that looks uncertain or inconsistent. The hesitation that catches a suspicious SQL interpolation — "wait, is that injectable?" — is quieter when the surrounding code looks professional. The mechanism isn't carelessness. It's what well-formatted, syntactically correct code communicates to reviewers trained to trust that signal.

Two practical implications follow for engineering teams. First, peer review processes for AI-generated PRs should include an explicit scanning step, not only visual review. The scanner catches structural patterns that visual review misses under overconfidence conditions. Second, PR reviewers should know they're reviewing AI-generated code — the Perry overconfidence effect is partly a calibration issue, and reviewers who know the source may apply more scrutiny to the output.

Veracode's 2025 State of Software Security report found average remediation time for security flaws has increased 47% over five years, to 252 days. A bug that ships in an AI-generated commit runs the same remediation sequence as any other production security bug: detection, log audit to bound the exposure window, credential rotation if the window is uncertain, compliance notification if regulated data was in scope. The commit velocity AI coding tools provide doesn't compress that timeline. What compresses the timeline is when the bug is caught. At commit, it's seconds. At production, it's months.

The Governance Gap

BrassCoders's scanner output goes to Claude Code or Cursor for AI-assisted triage — the AI reviewer reads the YAML, source-verifies each finding against the original file, and classifies each as real vulnerability or false positive with fix-ready advice. That division of labor (BrassCoders as deterministic pattern-matcher, AI reviewer as context-aware triage layer) is the technical architecture. The governance question is whether that architecture is required before AI-generated code can merge.

The Checkmarx 2025 data makes the gap concrete: 82% of organizations with active AI coding tool usage have no defined process for what review AI-generated commits require. The tooling problem is solvable in an afternoon. The governance problem is a management decision about what process is required.

Three decisions define a minimal AI coding governance policy:

What scans run before merge. At minimum, a static-analysis scan covering the categories AI assistants structurally miss: SQL injection, hardcoded credentials, unsafe subprocess calls, and phantom imports from AI hallucinations. BrassCoders OSS core covers all of these with no account required.

Who reviews scanner findings. Automated scanning produces findings; a human closes the loop. The AI reviewer (Claude Code, Cursor) does context-aware classification. The developer confirms. Without a defined owner, findings queue unreviewed.

What the verified false-positive process is. Some findings are false positives in context. .brassignore captures these decisions so they don't consume review cycles on future scans. A glob rule like file_dedupe.py suppresses all findings from a specific file; a type rule like :brass.python.taint.sql-injection suppresses a specific Semgrep check project-wide. Without a suppression process, teams tune out the scanner after the first wave of noise.

These three decisions don't require new tooling. They require the management decision that AI-generated code has a defined review process. That decision is what the 18% who have governance policies have made.

Building a Security Gate for AI-Generated Code

BrassCoders installs in one command and runs offline with no account required — the OSS core catches the structural bugs AI coding assistants produce without any data leaving the developer's machine.

pip install brasscoders
brasscoders scan /path/to/project

The scan emits YAML to .brass/findings.yaml, structured for Claude Code or Cursor consumption. Each finding includes severity, detector, file path, line number, and code snippet. The AI reviewer reads the file, verifies each finding against the source, and produces a triage output: real bug with fix advice, or false positive with reasoning. The scanner is the deterministic first layer. The AI reviewer is the context-aware second layer.

CI integration runs the scan on every commit:

# .github/workflows/brasscoders.yml
steps:
  - name: BrassCoders scan
    run: pip install brasscoders && brasscoders scan .

BrassCoders Paid ($12/developer/month) adds a semantic deduplication pass and project-signature reranking that reduces a 1500+ finding raw scan to approximately 300 prioritized findings. The enrichment pass processes already-redacted findings and a project signature derived from README, manifest, and entrypoint metadata — no raw source code leaves the machine. For teams where 1500 raw findings make AI-assisted triage impractical at scale, the enrichment pass is what makes the process work.

The engineering leadership version of this is binary: the gate runs in CI before merge or it doesn't. Perry, Veracode, and Checkmarx describe what happens when it doesn't. The gate costs one afternoon to wire and runs in seconds per commit.

Tuning .brassignore: Suppressing a False Positive in Three Steps

CopperSunDev — Sat, 08 Aug 2026 19:46:28 +0000

BrassCoders scans a file-deduplication script and returns a CRITICAL finding: MD5 used for security. The pattern match is correct — hashlib.md5() without usedforsecurity=False triggers Bandit B324 regardless of context. The problem is that content fingerprinting for deduplication is not a security use of MD5. Here's how to tell BrassCoders that.

The Starting Point: What the Scan Shows

BrassCoders's published N=15 AI-code-findings corpus includes file_dedupe.py, generated from the prompt "Write a script that finds duplicate files in a directory tree by hashing their contents." The model produced a working deduplication script using hashlib.md5():

import os
import hashlib

def find_duplicates(root):
    seen = {}
    duplicates = []
    for dirpath, _, filenames in os.walk(root):
        for name in filenames:
            path = os.path.join(dirpath, name)
            with open(path, "rb") as f:
                digest = hashlib.md5(f.read()).hexdigest()
            if digest in seen:
                duplicates.append((path, seen[digest]))
            else:
                seen[digest] = path
    return duplicates

Running brasscoders --offline scan /path/to/project on a project containing this file produces the following at line 19:

severity: critical
file_path: file_dedupe.py
title: Use of weak MD5 hash for security. Consider usedforsecurity=False
detected_by: bandit
also_detected_by: AstGrepScanner
line_number: 19
code_snippet: |
    with open(path, "rb") as f:
        digest = hashlib.md5(f.read()).hexdigest()
    if digest in seen:

Total findings for the project: 57. Three of those findings are on file_dedupe.py — the B324 CRITICAL, the AstGrepScanner confirmation, and one additional pattern overlap. All three are on the MD5 call.

Why This Finding Is a False Positive in Context

BrassCoders's Bandit scanner fires B324 on any hashlib.md5() call that doesn't explicitly declare usedforsecurity=False. The rule doesn't inspect how the digest is used after the call — whether it's checked against a stored credential, used to sign a token, or compared to another file's fingerprint for deduplication.

Two uses of MD5 are structurally identical in source:

# Authentication use (real vulnerability — MD5 is broken for this)
stored_hash = hashlib.md5(password.encode()).hexdigest()
if stored_hash == db_user.password_hash:  # attacker can find collisions

# Content fingerprinting (not a security use — collision attacks are irrelevant)
digest = hashlib.md5(f.read()).hexdigest()
if digest in seen:  # duplicate detection

MD5 collision attacks matter when an attacker can substitute a different input that produces the same hash — replacing a document with a forged one that has the same signature, or finding a password that matches a stored hash. For deduplication, you're asking "are these bytes identical?" A collision that produces the same hash for different content is irrelevant — the code would incorrectly report two different files as duplicates, not allow unauthorized access.

The scanner correctly reports the pattern. The context — if digest in seen for duplicate detection — makes it a false positive for security purposes.

Two Ways to Clear the Finding

BrassCoders surfaces the finding so you can decide: fix the code or suppress it. Both clear the finding from scan output.

Option 1 — Code fix (preferred when you own the file):

Python 3.9 added the usedforsecurity parameter to explicitly declare that a hash function is not being used for security purposes:

digest = hashlib.md5(f.read(), usedforsecurity=False).hexdigest()

With this flag, Bandit B324 no longer fires. The intent is documented in the source itself — any future reader, scanner, or AI reviewer sees the declaration. This is the right call when you control the file.

Option 2 — .brassignore glob (when you can't change the file):

If file_dedupe.py is a benchmark corpus file, vendored code, or a third-party script you're scanning but not modifying, add a glob rule to .brassignore at the project root:

# file_dedupe.py uses MD5 for content deduplication only — not a security use.
# usedforsecurity=False would be the code fix; suppressed here because this
# is a benchmark corpus reference file, not production code we own.
file_dedupe.py

Bare filenames in .brassignore match that file at any depth in the project tree. No anchoring needed.

The Re-Scan: From 57 to 54

After adding file_dedupe.py to .brassignore, the re-scan shows:

🙈 .brassignore: dropped 3 findings (57 → 54)

All three findings tied to file_dedupe.py are gone. The remaining 54 findings are from other files in the project — real bugs including SQL injection, command injection via shell=True, and unsafe subprocess calls that warrant review. The MD5 pattern no longer appears in the triage queue.

BrassCoders reads .brassignore before the noise-reduction pass. Suppressed findings never enter the ranking pipeline. For the Paid plan, they also never reach the enrichment step — suppressed findings don't consume enrichment tokens.

The CLI message is the confirmation to check for. If the message doesn't appear, either the .brassignore file wasn't found at the project root or the glob rule didn't match the finding's file path. The --offline flag goes before scan in the command:

brasscoders --offline scan /path/to/project

When to Suppress vs When to Fix

BrassCoders's .brassignore is the right tool for findings in code you don't own or can't change. The decision is straightforward:

Fix the code when you own it. The usedforsecurity=False parameter is the explicit declaration that removes the finding and documents intent. A future reader — or another scanner — sees the decision in the source without needing to cross-reference a suppression file.

Use .brassignore when you can't change the file. Vendored libraries, auto-generated code, third-party integrations, and benchmark corpus reference files are all cases where you've verified the finding is a false positive but can't or shouldn't modify the source. The glob rule suppresses the finding without touching the file.

For patterns that appear across many files — a privacy rule, a Semgrep check ID — .brassignore supports type rules via the :rule_id syntax. Semgrep findings store their check ID as rule_id in metadata; the type rule :brass.python.taint.sql-injection suppresses BrassCoders's SQL injection taint rule project-wide. Bandit findings store the test ID as bandit_test_id rather than rule_id, so per-file glob rules are the supported suppression path for Bandit.

The fuller catalog of .brassignore patterns for Django projects, FastAPI projects, and test fixture directories is at /blog/tuning-brasscoders-brassignore/. The distinction between .brassignore and .gitignore — two independent files with different jobs — is at /blog/what-is-the-difference-between-brassignore-and-gitignore/.

pip install brasscoders
brasscoders --offline scan /path/to/project
# Review findings. For confirmed false positives: fix the code or add to .brassignore.

From HIGH to Clean: Removing a Hardcoded HMAC Key in AI-Generated Python

CopperSunDev — Sat, 08 Aug 2026 03:12:41 +0000

The model wrote what you asked for. The prompt said "include a usable example so I can run it" — and the model gave you one, complete with SECRET_KEY = "s3cr3t-signing-key-change-me" hardcoded in source. BrassCoders flags that assignment as HIGH severity on the first scan: confidence 0.85, impact_score 0.9, secret_type "Secret Keyword."

Two lines of code fix it. Here's the full walkthrough, with real scan output.

The Starting Point: The Prompt Asked for a Runnable Example

BrassCoders's published corpus includes token_check.py, generated from the prompt "Write a function that signs and verifies a session token using HMAC. Include a usable example so I can run it." The phrase "Include a usable example" is the instruction that produces the credential — the model needs a key to sign with, so it fills one in.

This pattern recurs across AI-generated auth and signing code. The demo needs a working value. The model produces a placeholder-looking string, the code runs, the developer commits it. "s3cr3t-signing-key-change-me" reads like a reminder to swap it out — but it's still a hardcoded literal in version-controlled source until someone does.

A placeholder key with "change-me" in the name signals intent without enforcing it. No runtime error fires. Deploys succeed. HMAC signatures verify correctly in tests. The production deploy looks identical to the local demo. There's nothing to alert on until someone checks whether the key is actually loaded from a safe source.

The file that came out of the model:

import hmac
import hashlib

SECRET_KEY = "s3cr3t-signing-key-change-me"

def sign(payload):
    mac = hmac.new(SECRET_KEY.encode(), payload.encode(), hashlib.sha256)
    return mac.hexdigest()

def verify(payload, signature):
    expected = sign(payload)
    return hmac.compare_digest(expected, signature)

if __name__ == "__main__":
    sig = sign("user=42")
    print(verify("user=42", sig))

The HMAC logic is correct. hmac.compare_digest is the right comparison function — timing-safe, no short-circuit on mismatch. The bug isn't the signing implementation. It's the key source.

Running the Scan: What BrassCoders Surfaces

BrassCoders's SecretsScanner — built on detect-secrets, the upstream credential-pattern library from Yelp — catches the SECRET_KEY assignment at line 11 with HIGH severity. The finding title is "Possible hardcoded credential" and the exact value is redacted in the .brass/ai_instructions.yaml output, so the findings file doesn't re-expose the secret.

The scan command:

brasscoders scan /path/to/corpus/

The finding in the YAML output:

- title: "Possible hardcoded credential (value redacted)"
  file: token_check.py
  line: 11
  detector: SecretsScanner (detect-secrets)
  description: >
    Variable assignment: SECRET_KEY. A credential-shaped literal was
    detected at this location. The exact value has been redacted to
    prevent the brass output from re-exposing it.
  confidence: 0.85
  impact_score: 0.9
  secret_type: "Secret Keyword"
  also_detected_by: bandit (B105)
  remediation: >
    Confirm whether this value is a real credential. If yes: rotate it
    immediately, remove it from history, and load it from a secrets
    manager or environment variable.

Notice what's absent: no code_snippet field. BrassCoders redacts credential-shaped values from the findings file by design. The output points to the file and line number — enough to locate and fix the credential — without reproducing the string in the YAML. If the findings file contained the literal, the findings file would be another place the secret lives.

The severity classification comes from two signals. The detect-secrets "Secret Keyword" pattern scores based on variable name: SECRET_KEY is a high-confidence credential signal. The impact_score of 0.9 reflects what this credential class controls — an HMAC signing key governs session token validity, so a compromise breaks the authentication boundary entirely, not just leaks a piece of data.

The also_detected_by: bandit (B105) field shows Bandit fired on this file too. B105 is Bandit's generic hardcoded-password-string rule, which triggers on obviously-named credential assignments. In this case, both tools fire. The SecretsScanner is the primary signal because detect-secrets also applies entropy analysis, covering cases where the variable name is less obvious but the value's entropy is high enough to classify as a credential. B105 alone would miss those.

The Fix: Load From Environment

BrassCoders's remediation note for the credential finding is direct: rotate if real, then load from a secrets manager or environment variable. For token_check.py, os.environ.get("HMAC_SECRET_KEY", "") replaces the literal with a runtime-loaded value. The key never appears in source, in git history, or in build artifacts once the commit is cleaned.

The fix is two lines added to the import block:

import os

SECRET_KEY = os.environ.get("HMAC_SECRET_KEY", "")

The empty-string default lets the module import cleanly. Add a startup guard if you want the process to fail fast on a missing key rather than at signing time:

if not SECRET_KEY:
    raise RuntimeError("HMAC_SECRET_KEY not set")

One step matters before removing the literal from source: check whether the key was ever deployed. If "s3cr3t-signing-key-change-me" reached production, any party with the source can forge tokens signed with it. Rotate first. Then clean the history. For git history removal, git filter-repo is the current recommended tool — it rewrites history, which requires a force push and coordination with anyone who has cloned the repo. The safer path, when the key was never deployed, is to make the environment-variable change in a new commit and leave the history in place.

.brassignore suppresses the BrassCoders finding. It does not remove the string from past commits. That's not the right tool here.

The full fixed file:

import hmac
import hashlib
import os

SECRET_KEY = os.environ.get("HMAC_SECRET_KEY", "")

def sign(payload):
    mac = hmac.new(SECRET_KEY.encode(), payload.encode(), hashlib.sha256)
    return mac.hexdigest()

def verify(payload, signature):
    expected = sign(payload)
    return hmac.compare_digest(expected, signature)

if __name__ == "__main__":
    sig = sign("user=42")
    print(verify("user=42", sig))

The Re-Scan: Zero Credential Findings

BrassCoders's re-scan of the fixed file shows SecretsScanner and Bandit B105 both silent — the credential-shaped literal is no longer present in source, so neither tool fires. The only remaining findings are Pylint code quality items for missing docstrings: zero security findings, zero HIGH or CRITICAL severity.

The scanner summary after the fix:

Secrets detection:  0 findings  ✓
Bandit (security):  0 credential findings
Pylint (quality):   2 findings  (missing docstrings — code quality, not security)

Critical issues:    0
High issues:        0

The Pylint warnings are legitimate. The functions have no docstrings, and Pylint will note that. Worth addressing in production code — but these are in a different category from the credential finding, and the security surface is clean.

Two credential findings before the fix. Zero after. The Pylint items were always present; SecretsScanner took priority in the first output.

What BrassCoders Doesn't Verify

BrassCoders catches the presence of a credential-shaped literal — it cannot determine whether the value in source was ever used to sign real session tokens in production. That determination belongs to the incident response workflow: check deployment history, determine the exposure window, decide whether to rotate.

Detection time is when you know to start checking. If "s3cr3t-signing-key-change-me" was copied directly into a production deploy, any party who reads the source can verify or forge tokens signed with it. The scan tells you to look; it doesn't tell you what was looked at before you scanned.

BrassCoders catches 20+ secret formats through detect-secrets plus 7 custom patterns — AWS access keys, GitHub PATs, Stripe live keys, OpenAI API keys, Slack tokens, PEM-formatted private keys, JWTs, and high-entropy strings, among others. The HMAC key here triggers the "Secret Keyword" pattern: variable name contains a credential-signal word, assigned a string literal. The same pattern fires on API_KEY, TOKEN, PASSWORD, and similar assignments across a codebase.

Run brasscoders scan before you commit. The scan takes seconds. The credential investigation, after the fact, takes longer.

From SQL Injection to Clean: Fixing a B608 Finding in AI-Generated Flask Code

CopperSunDev — Sat, 08 Aug 2026 01:45:51 +0000

The endpoint is 15 lines of Python. It queries a user by ID and returns the record as JSON. claude-opus-4-8, given the prompt "Write a small Flask endpoint that returns a user record by id from a sqlite database as JSON," produced it in one shot. The code compiles. The route works. The SQL injection runs without a second prompt.

BrassCoders finds it on the first scan — two CRITICAL findings and one HIGH, all pointing at the same line.

The Starting Point: What the Model Generated

BrassCoders's published N=15 AI-code-findings corpus includes user_lookup.py, generated from the prompt "Write a small Flask endpoint that returns a user record by id from a sqlite database as JSON." The model produced a working Flask endpoint that connects to a SQLite database and returns user records as JSON. It also produced SQL injection at line 22, where the query string is built by Python string formatting.

Here's the generated file:

import sqlite3
from flask import Flask, jsonify

app = Flask(__name__)

def get_db():
    return sqlite3.connect("app.db")

@app.route("/user/")
def get_user(user_id):
    conn = get_db()
    cur = conn.cursor()
    cur.execute("SELECT id, name, email FROM users WHERE id = %s" % user_id)
    row = cur.fetchone()
    conn.close()
    if row is None:
        return jsonify({"error": "not found"}), 404
    return jsonify({"id": row[0], "name": row[1], "email": row[2]})

if __name__ == "__main__":
    app.run(debug=True)

The injection is on the cur.execute line. Python's %s substitution runs before the query reaches SQLite — user_id arrives from the URL as a raw string, and Flask passes it through without modification. An attacker sends /user/1 OR 1=1 and the formatted query becomes SELECT id, name, email FROM users WHERE id = 1 OR 1=1. Every row in the users table comes back. A more destructive payload — /user/1; DROP TABLE users; -- — produces a multi-statement string that some driver configurations will execute.

The corpus file is one of 15 files in BrassCoders's published AI-code-findings set, each generated by a frontier model responding to a plausible engineering prompt, each scanned and committed with full provenance. user_lookup.py is one of the cleaner cases. The prompt was specific, the implementation was idiomatic Flask, and the vulnerability is textbook.

The model got the route shape right. The JSON response right. One thing wrong.

Running the Scan: What BrassCoders Reports

BrassCoders catches the injection on the first scan — two CRITICAL findings at line 22 from input_validation_analyzer and SemgrepTaintScanner, both confirmed by Bandit as well. The code_snippet field in the YAML output shows the exact injected line, not just the file or function name.

Run the scan against the corpus with:

brasscoders --offline scan /corpus/files --no-enrich

Three findings surface:

input_validation_analyzer — CRITICAL — line 22
Title: Input Validation Vulnerability: Sql Injection Risk
Description: User input appears to be directly used in SQL queries without proper sanitization
Code snippet: cur.execute("SELECT id, name, email FROM users WHERE id = %s" % user_id)
Also detected by: bandit

SemgrepTaintScanner — CRITICAL — line 22
Title: Tainted dataflow: sql injection
Description: Tainted HTTP request data reaches a SQL execution sink without parameterization
Code snippet: cur.execute("SELECT id, name, email FROM users WHERE id = %s" % user_id)
Also detected by: bandit

bandit — HIGH — line 31
Title: Flask app run with debug=True

Two independent detectors landing on the same line, both confirmed by a third, is the pattern worth acting on immediately. Bandit's B608 rule — documented at bandit.readthedocs.io — fires specifically on formatted strings (%s, f-strings, .format()) appearing in SQL query contexts. The also_detected_by field in the BrassCoders YAML tells Claude Code that multiple scanners agreed on the same line; that cross-scanner confirmation is the signal to weight heavily in triage.

The debug=True finding is separate. Flask's debug mode activates the Werkzeug interactive debugger; any unhandled exception exposes an in-browser Python shell. That's a code execution surface if the app reaches production.

The Fix: Parameterized Query

BrassCoders's remediation note for both CRITICAL findings says the same thing: use prepared statements. SQLite's positional placeholder is ?, passed as a tuple in the second argument to cursor.execute() — the sqlite3 module sends the query string and the bound value to the database library separately, so no user-controlled data ever interpolates into the query text.

The fixed line:

cur.execute("SELECT id, name, email FROM users WHERE id = ?", (user_id,))

The query string stays fixed at SELECT id, name, email FROM users WHERE id = ?. The user_id value binds inside the sqlite3 module, not in Python string formatting. Python's sqlite3 documentation at docs.python.org/3/library/sqlite3.html calls this "DB-API 2.0 parameter substitution" — the value is transmitted to SQLite's C library as a typed parameter, never concatenated into the SQL text. No amount of SQL syntax in the user_id value changes the query structure.

Note the driver difference: psycopg2 (PostgreSQL) uses %s as its placeholder, with a values tuple rather than %-string formatting. cursor.execute("SELECT ... WHERE id = %s", (user_id,)) is safe in psycopg2; cursor.execute("SELECT ... WHERE id = %s" % user_id) is not. The placeholder syntax varies by driver; the principle of binding values separately from the query string applies everywhere. This distinction is how the bug survives code review — the two forms look similar at a glance.

Fix the debug flag at the same time:

app.run(debug=False)

The full fixed file:

import sqlite3
from flask import Flask, jsonify

app = Flask(__name__)

def get_db():
    return sqlite3.connect("app.db")

@app.route("/user/")
def get_user(user_id):
    conn = get_db()
    cur = conn.cursor()
    cur.execute("SELECT id, name, email FROM users WHERE id = ?", (user_id,))
    row = cur.fetchone()
    conn.close()
    if row is None:
        return jsonify({"error": "not found"}), 404
    return jsonify({"id": row[0], "name": row[1], "email": row[2]})

if __name__ == "__main__":
    app.run(debug=False)

Two characters change in the query string. One argument added. The route logic and the response format are identical.

The Re-Scan: What Changes and What Remains

BrassCoders's re-scan of the fixed file shows the input_validation_analyzer and Bandit findings gone — the %s format pattern no longer appears in a SQL context, so neither rule fires. The debug=True finding is gone. One finding remains: Semgrep's taint rule fires at line 23 with the title "Tainted dataflow: sql injection."

This is a known false positive on correctly parameterized SQLite calls. Semgrep's python taint rule tracks data flows from user-controlled sources — in this case, the user_id Flask route parameter — to SQL execution functions like cursor.execute(). The rule fires whenever it sees user-controlled data reaching the call, parameterized or not. It doesn't distinguish cur.execute(query % user_id) from cur.execute(query, (user_id,)). To the taint rule, both forms deliver user-controlled data to a SQL execution sink.

The (user_id,) tuple form is safe. The fix is correct.

This is where the BrassCoders + Claude workflow handles the residual. The scanner narrows scope from 3 findings to 1 — both CRITICALs gone, the HIGH gone. Claude Code reads the surviving Semgrep finding, sees the parameterized tuple syntax in the code_snippet field, and marks it a false positive. Three findings reduced to one triage decision, and the triage takes seconds.

The reduction matters in practice. Before the fix, Claude reading the YAML sees two CRITICAL entries with identical code snippets, plus a HIGH for debug=True. After the fix, one taint finding on a parameterized call. The cognitive surface drops; the reasoning path is shorter.

What BrassCoders Doesn't Check

BrassCoders's SQL injection findings confirm the structural pattern: a string-formatted query reaching an SQL execution sink. They don't verify whether the authenticated user is authorized to look up the requested user_id — that authorization question requires business-logic context no scanner can infer from source alone.

The route in user_lookup.py has no authentication decorator. No @login_required, no session check, no ownership validation. Any caller who hits /user/ gets the record if it exists — including records that don't belong to them. Whether that's a bug or a deliberate public endpoint depends on the application design, and BrassCoders has no way to know from source structure alone.

Claude Code, reading the BrassCoders YAML output in context, can surface this. The scanner reports the structural pattern; the AI triage layer reads the findings alongside the actual code and flags concerns the scanner didn't touch. That division of labor is built into how BrassCoders formats its output — the YAML is structured for AI consumption, so Claude can reason about what the scanner found and note what it didn't reach.

The corpus is Apache 2.0 licensed and the scan is reproducible. Install brasscoders via pip install brasscoders, clone the OSS repo at github.com/CopperSunDev/brasscoders, and run brasscoders scan docs/benchmarks/ai-code-findings-corpus/files. The SQL injection finding appears at user_lookup.py:22. The re-scan behavior after the ? fix matches exactly what's described above.

What Static Analysis Cannot See: A Complete Map of the Limit

CopperSunDev — Sat, 08 Aug 2026 00:23:37 +0000

SQL injection through a formatted string: BrassCoders catches it on every scan, byte-identical, at the exact line. Missing authentication on an /admin route: no static analyzer catches it without knowing which routes require authentication — a fact that lives in the spec, not the source file. The gap between those two cases is not a tool limitation. It's a category limit.

Static analysis matches patterns against source code structure. It can report only what the structure encodes. Every bug that depends on runtime state, caller intent, architectural policy, business rules, or deployment configuration sits outside that boundary — not because the tool is weak, but because those facts are not encoded in the source.

That distinction matters for teams shipping AI-generated code. AI assistants produce code that looks structurally sound while burying context-dependent bugs in the logic. A scanner catches the structural part. An AI assistant doing triage catches the rest. Neither layer replaces the other, and confusing their roles wastes both.

Quick Navigation

What "Can't See" Means for a Pattern Scanner
What BrassCoders Catches Deterministically
What Requires Context the Scanner Can't Have
The Bug-Category Visibility Table
What False Positives Reveal About the Boundary
How the Two Layers Compose
What BrassCoders's Findings File Gives the AI Assistant

What "Can't See" Means for a Pattern Scanner

BrassCoders reports what has a structural marker in the source — patterns its 12 scanners can match deterministically on every run. What it cannot see is everything that depends on context the source code doesn't encode: intent, runtime state, caller provenance, business rules, production data distribution.

A structural marker is something an AST traversal finds without executing the code. The string f"SELECT * FROM users WHERE id={user_id}" is a structural marker for SQL injection: its AST contains a formatted string with a SQL keyword prefix and an interpolated variable, a pattern the rule matches deterministically on every run, regardless of where user_id came from or what database is running.

When there's no structural marker, the scanner has nothing to match against. A route handler that calls an admin-only query carries no "requires authentication" annotation in the AST. The requirement exists in a product document or in the developer's intent at the time of writing. Pattern rules evaluate syntax, not intent.

The implication is that the boundary isn't fuzzy. It's precise: a pattern with a fixed structural shape can be matched; a fact that requires executing the code, reading documentation, or knowing the deployment environment cannot. That boundary is the fundamental property that makes the scanner deterministic, not a shortcoming to engineer away. Give up the pattern-only constraint and you give up the guarantee of identical results on identical code.

What BrassCoders Catches Deterministically

BrassCoders's 12 scanners — Bandit, Pylint, Pyre/Pysa, Semgrep, ast-grep, detect-secrets, and six custom detectors — catch what has a fixed structural shape: SQL injection via string formatting (Bandit B608), shell injection (B602/B603), hardcoded credentials (detect-secrets), unsafe deserialization (B506), and phantom imports that don't exist on PyPI.

Each of these fires on every scan, byte-identical for the same commit. A formatted SQL string on line 42 today is the same finding on line 42 after twenty commits to unrelated files. That repeatability is what a CI gate requires: a check that fails consistently on the same code and passes consistently on clean code. A 2025 study by Gnieciak and Szandala, Large Language Models Versus Static Code Analysis Tools, measured this gap directly: deterministic analyzers pointed at the exact line while LLM reviewers mislocated findings due to tokenization artifacts. The LLMs led on recall; precision and exact localization lagged.

BrassCoders's JavaScript and TypeScript scanner (one of the six custom detectors) extends the same approach to six JS and TS file types via Babel AST parsing. The patterns it targets — eval() calls, dangerous innerHTML assignments, document.write usage, hardcoded API keys, and hardcoded passwords — are structural markers, the same category as the Python findings. Semgrep also runs against those file types; Bandit is Python-only and does not.

The structural coverage across categories is documented in BrassCoders's published benchmark: across 12 AI-generated bug categories, BrassCoders's scanners catch 11; Bandit running alone catches 6. For the corpus and scoring, see the full benchmark at /blog/ai-coder-bug-benchmark/. What makes these findings useful in CI is stability: the same code produces the same result on every run. That property is what Why AI Code Needs a Deterministic Gate, Not Just an LLM argues for with the Gnieciak benchmark as evidence.

What Requires Context the Scanner Can't Have

BrassCoders cannot determine whether a division operation will receive a zero denominator, whether a route requires authentication, or whether a query runs in O(N²) time against production-scale data — because these answers depend on runtime facts, architectural decisions, and domain knowledge that aren't encoded in the source file.

Four categories account for most of the scanner's blind spots.

Runtime behavior. A division that fails on a zero denominator only fails when that input arrives. The source shows the operation; it doesn't show the call path or what values flow to it across call boundaries. A ZeroDivisionError in a rarely-executed branch has no structural marker until it throws. The same applies to null-style errors in dynamically typed code: the source shows the attribute access, not the object's actual type at runtime. Logic Bugs No Scanner Can See works through concrete examples of context-dependent correctness bugs that require tracing call paths to find.

Authorization policy. Whether /api/admin/delete-user requires authentication is a policy decision. The source might show a decorator, or it might not — but knowing that it should have one requires reading the auth model and the route map together. BrassCoders flags an endpoint that lacks a recognizable auth decorator in a supported framework, but it cannot know the application's complete auth requirements from source alone. IDOR vulnerabilities, where a route accepts a user-controlled ID without checking ownership, are invisible at the structural level: get_record(user_id=request.args['id']) looks identical whether or not the result is ownership-checked. The Authorization Bug No Scanner Understands covers why these bugs fall outside static analysis.

Performance under production data. O(N²) behavior is visible only when data size context is known. String concatenation in a loop has a structural marker; a list prepend that degrades on a million-row dataset is structurally identical to one that runs fine on ten rows. The performance issue depends entirely on how large the input grows in production — a number the scanner doesn't have. The Slow Code No Scanner Can Flag makes the data-size argument with a concrete example.

Runtime configuration. Whether DEBUG=True reaches production, whether TLS is enforced in the deployment config, whether an environment variable points at the right secret store — these are facts determined at deploy time, not scan time. The source might contain DEBUG = os.getenv('DEBUG', 'false'), but what value the environment injects is invisible to the scanner. Security Misconfiguration Is a Runtime Fact covers the environment-dependent bug pattern and why it requires examining the deployment context alongside the source.

The Bug-Category Visibility Table

BrassCoders classifies every finding it surfaces as a structural pattern — not because it's uncertain, but because the scanner sees structure, not intent. The table below maps bug categories to scanner visibility.

Bug Category	Scanner Visibility	What the AI Assistant Adds
SQL injection via f-string	✅ Deterministic (Bandit B608)	Confirms real query vs test fixture
Hardcoded credentials	✅ Deterministic (detect-secrets)	Confirms real credential vs FIXTURE placeholder
Command injection via shell=True	✅ Deterministic (Bandit B602/B603)	Confirms user-controlled input reaches the call
Unsafe deserialization (yaml.load, pickle)	✅ Deterministic (Bandit B506/B301)	Confirms external input reaches the deserializer
Phantom imports (PyPI cross-reference)	✅ Deterministic (AI-pattern scanner)	Verifies whether package exists at scan time
Missing auth on a route	❌ Needs route map + policy	✅ AI reads the application structure
ZeroDivisionError in untested path	❌ No structural marker	✅ AI traces the call path for zero-denominator inputs
O(N²) loop under production data	Partial (string-concat pattern)	✅ AI sees data size context
Race condition in asyncio	Partial (threading patterns)	✅ AI traces shared state across await points
Business logic rule violation	❌ No structural pattern	✅ AI reads intent from the requirements context
Runtime config error (wrong env variable)	❌ Runtime fact	✅ AI knows the deployment environment

The partial entries deserve attention. String concatenation in a loop gets a partial flag because the AST pattern (accumulator on the right side of += inside a loop body) is visible in the parse tree. Whether the accumulator holds a string depends on type inference the scanner doesn't run. BrassCoders flags the pattern; the AI assistant reads the variable declaration, the type annotation if present, and the surrounding call context to confirm.

Threading race conditions follow the same logic. threading.Thread without paired locks, and global mutable state in async functions, have structural markers BrassCoders matches. Asyncio races that leave no structural marker — two coroutines sharing state through an await point, with no visible locking primitive — require tracing the control flow across await boundaries. That's the AI's work.

Business logic violations fall entirely outside the green zone. Whether a coupon discount can be applied twice to the same order depends on a rule in a product document, not a pattern in the source. The source shows the discount being applied; it doesn't show whether the invariant is checked before or after. The AI assistant, given the requirements document alongside the code, can evaluate the invariant. The scanner cannot — because the invariant isn't in the file.

What False Positives Reveal About the Boundary

BrassCoders's false positives are structural — they occur when the scanner matches the pattern but the context makes it safe. A hardcoded credential in a test fixture with a FIXTURE-marked placeholder matches the detect-secrets pattern; the AI triage layer reads the fixture context and marks it a false positive.

This is the boundary made concrete. The scanner did its job: it found a pattern that matches the shape of a real credential. Deciding the value is a placeholder requires reading the variable name, the file path, the fixture directory context, and the FIXTURE annotation — information that isn't in the pattern rule. The AI reads it in a second. The division works.

It's worth pausing on the alternative: a scanner that suppresses findings when it infers fixture context. That scanner would stop reporting the credential in the test fixture. It would also stop reporting a real credential in a file a developer accidentally named test_helpers.py, or in a fixture file that was later refactored to hold production configuration. Inference-based suppression removes false positives and real bugs through the same mechanism — because the structural patterns are identical. The scanner can't know which is which without context.

The False Positive Is a Feature, Not a Bug works through BrassCoders's N=15 corpus scan in detail: 53 raw findings collapsing to 9 confirmed real security issues after one triage pass. It shows the false-positive cases — the counter-increment that looks like a string-concat loop, the MD5 call in a deduplication context — and explains why each context-based suppression would carry a corresponding risk. The ratio looks noisy; the triage session is fast. That's the design.

How the Two Layers Compose

BrassCoders runs first, narrows the scope to confirmed structural patterns, and emits a YAML file the AI assistant reads. The AI assistant verifies each finding in context — confirming whether the injection is real, whether the credential is a fixture, whether the route actually needs auth. Neither layer alone covers the full surface.

A raw AI review of an unscanned codebase starts from scratch: it reads the full source without any priority signal for what matters, and results vary run to run. A post-BrassCoders AI review starts from a prioritized work queue with exact line numbers and remediation notes. The AI spends its time on confirmation, not discovery — and answering a specific question about a specific line is faster and more reliable than open-ended review. Why Your AI Assistant Needs a Deterministic Pre-Pass describes this architecture and the practical speedup it produces.

A 2025 paper, ZeroFalse, measured this combination directly: feeding static-analyzer output to an LLM for adjudication produced F1 scores of 0.912 on the OWASP Java Benchmark and 0.955 on the OpenVuln dataset, with precision and recall above 90%. The pattern in the paper is the same BrassCoders uses: deterministic detection first, model judgment second.

Configuration bugs fit the composition exactly. BrassCoders catches debug=True in a Flask application as a structural flag — the literal Boolean in the source. Whether that value reaches production depends on how the environment variable loading chain works, which deploy scripts override it, and what the hosting environment sets. The AI assistant, reading the deployment scripts alongside the .brass/ai_instructions.yaml, can trace that chain. BrassCoders surfaces the lead; the AI confirms whether it's a real exposure. Security Misconfiguration Is a Runtime Fact shows how the combination handles this on a concrete deployment example.

What BrassCoders's Findings File Gives the AI Assistant

BrassCoders's .brass/ai_instructions.yaml gives an AI assistant a pre-digested work queue — severity, scanner rule, file path, line number, and remediation note for each finding — so it triages structured patterns rather than reading the full codebase from scratch.

The file has three sections. Findings sorted by severity lead the file, so the AI addresses critical and high-severity issues before low-severity style notes. Critical findings — SQL injection, command injection, hardcoded credentials, unsafe deserialization — appear first. The AI starts where the risk is highest. Scanner metadata follows: which of the 12 scanners ran, at what version, and how long the scan took. That section lets an AI assistant identify which rule engine fired and what its coverage scope is.

The third section, how_to_read_this_file, is a plain-language note explaining that BrassCoders is a pattern reporter, not a verdict machine. Findings are leads, not confirmed bugs. The AI's job is source verification on each flagged line — confirm it or dismiss it. That framing is why the triage session runs fast: the AI arrives knowing what to do with a finding, not wondering whether it can trust the verdict.

That contract produces a clean handoff. The scanner runs in seconds on a fresh commit. The YAML lands in the .brass/ directory. Claude Code or Cursor reads the file, opens the flagged lines, and runs the triage session against a bounded list of structural findings. The open-ended question ("what might be wrong?") becomes a specific list ("is this pattern a real bug in this context?"). The limit the scanner cannot cross is exactly where the AI assistant picks up — and the YAML format is what makes the crossing work at speed.

pip install brasscoders
brasscoders scan .
# .brass/ai_instructions.yaml is ready for your AI assistant

How to Run Your First BrassCoders Scan on AI-Generated Python

CopperSunDev — Sat, 08 Aug 2026 00:22:58 +0000

brasscoders scan runs 12 static-analysis scanners against your project tree and writes the results to a single YAML file — .brass/ai_instructions.yaml — built for AI assistants to read.

Install BrassCoders from PyPI and point it at your project:

pip install brasscoders
brasscoders scan /path/to/your/project

Zero configuration required. The scan runs locally — no account, no activation key — against your full source tree: Python and JavaScript/TypeScript files alike. When it finishes, the .brass/ directory appears at your project root. The OSS core makes zero outbound network calls; everything happens on your machine.

The resulting .brass/ai_instructions.yaml file groups findings by severity, CRITICAL down to LOW. Each entry names the scanner that flagged it — Bandit for Python security issues, or detect-secrets for credential patterns — along with the file path, line number, and a short remediation note. A scanner_metadata section records which of the 12 scanners ran and how many findings each produced. At the top sits a how_to_read_this_file block. It describes the field structure and orients your AI assistant before it reads a single finding.

Open the file in Claude Code or paste its contents into a Cursor chat. Each finding already names its source scanner, so the AI assistant knows the detection method before triage starts. The how_to_read_this_file header handles orientation — it describes each field and explains the severity tiers, so you get a triage conversation from the start. You don't need to prompt for context.

For air-gapped machines or compliance-sensitive environments, add the --offline flag before scan: brasscoders --offline scan /path/to/your/project. The flag position matters — it must come before scan, not after. If the scan attempts any network call at runtime, it exits non-zero. That's a process-level guarantee rather than a behavioral default.

The OSS core is Apache 2.0 licensed and installs with a single pip command. The .brass/ directory it creates is safe to add to .gitignore.

What's the Cost of a SQL Injection in AI-Generated Code?

CopperSunDev — Sat, 08 Aug 2026 00:22:25 +0000

SQL injection caught at commit time costs seconds. The same finding caught in production — or after active exploitation — costs engineering weeks.

The gap is structural. Without a scanning gate at commit time, a SQL injection bug lives in your codebase until a penetration test, a security audit, or an incident surfaces it. That window is typically weeks to months. During that window, the code runs against a real database with real credentials.

When the vulnerability surfaces (or is suspected after an incident), the repair scope expands well past the code fix itself. The parameterized-query patch takes minutes. What follows doesn't:

Log audit: Query logs must be reviewed to determine whether the injection path was ever triggered, and by what inputs.
Credential rotation: If the database was reachable during the exposure window, you cannot determine without forensic analysis whether credentials were exfiltrated — so rotation is the default safe action.
Compliance notification: If the database held regulated data (PII, health records, or payment data), most jurisdictions require breach notification within a defined window. The notification cycle spans person-weeks across legal, engineering, and communications.

BrassCoders catches the Bandit B608 rule at commit time, in the OSS core. The scan makes zero outbound network calls and completes in under a second. B608 fires on string-formatting operations interpolated directly into SQL query strings. The pattern that triggers it:

# B608 fires here — caller-supplied value interpolated into the query string
query = f"SELECT * FROM users WHERE name = '{name}'"

The parameterized fix eliminates the interpolation entirely:

cursor.execute("SELECT * FROM users WHERE name = ?", (name,))

The database driver sends the query structure and the value as separate arguments. No input can alter the query's structure, because the structure is fixed before the value arrives.

BrassCoders emits the B608 finding with severity HIGH, the file path, and the line number in .brass/ai_instructions.yaml. Claude Code or Cursor reads that file and generates the parameterized version from the flagged line. The finding is deterministic — same commit, same output, every scan — which makes a CI gate on it reliable: the finding either appears or it doesn't.

Adding brasscoders scan to a GitHub Actions or GitLab CI step catches B608 before any branch merges. The OSS core is free. The full ready-made workflow is in the BrassCoders open-source repository at github.com/CopperSunDev/brasscoders. The cost of running it is a few seconds per commit. The cost of not running it is measured in the engineering hours described above.

Can BrassCoders Catch Race Conditions in Async Python?

CopperSunDev — Sat, 08 Aug 2026 00:21:49 +0000

Partially. BrassCoders catches two structural patterns that indicate missing synchronization: calls to threading.Thread without a paired threading.Lock, and global mutable state modified inside async def functions. Both leave a deterministic marker in the source that the scanner can match.

The threading.Thread case is the cleaner catch. Spin up threads over functions that read and write shared state, and the scanner sees the thread call and checks for an associated lock. No lock: flagged. The async function plus global mutation pattern works the same way — the AST shows a global variable being written inside an async def, a structural sign of a potential race.

What BrassCoders cannot catch: the asyncio race that happens when two coroutines share a variable across an await point but no threading call is present. Python's asyncio event loop is single-threaded and cooperatively scheduled — any await expression is a potential handoff to another coroutine, and shared state written before and after that handoff can end up stale. But if the code contains no threading.Thread call and the variable isn't at module scope, there's no marker to match. Two coroutines reading and writing the same variable across an await looks structurally identical to two coroutines doing so safely.

The gap gets filled in two ways. An AI assistant — Claude Code, Cursor, or similar — reading the YAML output can trace which variables are actually shared across await points and flag missing asyncio.Lock usage. That kind of reasoning needs full function-body context, which deterministic rules can't supply. asyncio-specific linters can catch some of the same patterns, though at the cost of more false positives than BrassCoders targets.

One practical distinction worth making: when the shared state is auth data or a session store, the correctness bug becomes a security bug. A stale counter is a metrics error. A stale session token map that briefly exposes one user's state to another is a real vulnerability.

The full mechanics — how asyncio's cooperative scheduling creates race windows and what fixes them — are in Race Conditions in AI-Generated Concurrent Python.

Does BrassCoders Scan Node.js and TypeScript Code?

CopperSunDev — Sat, 08 Aug 2026 00:21:08 +0000

Yes. BrassCoders scans JavaScript and TypeScript files automatically in the same pass as Python. Two scanner layers run against your JS/TS code: BrassCoders's dedicated JavaScript/TypeScript scanner, built on Babel's AST parser, and Semgrep, which also runs rules against JS/TS files.

The Babel-based scanner operates on .js, .jsx, .ts, .tsx, .mjs, and .cjs files. Because it parses code into an abstract syntax tree rather than matching raw text, findings track the structure of your code rather than its whitespace or formatting. Five security patterns trigger findings:

eval() calls (dangerous_eval): a primary code-injection vector
innerHTML assignments (innerHTML_usage): the most common XSS source in browser-side JavaScript
document.write() calls (document_write): a secondary DOM-based XSS path
String literals matching common API key formats (potential_api_key)
Hardcoded password strings (hardcoded_password)

Semgrep runs its own rule set against the same files in the same scan. The two layers are complementary: Semgrep covers patterns defined in its OSS ruleset; the Babel scanner adds AST-level analysis that survives identifier renames and code reformatting.

Where Bandit fits — and where it doesn't: Bandit is Python-only. BrassCoders runs Bandit as one of its 12 scanners, but only against Python files. If you're asking because you assumed Bandit covered your Node.js backend, it does not. That work goes to the Babel scanner and Semgrep.

The gap compared to Python coverage: The Python scanner set — Bandit with 50+ rules alongside Pylint, Pyre/Pysa, and six custom scanners — is broader than the JS/TS layer. There's no JS/TS equivalent to Bandit's rule depth or to Pyre's interprocedural taint analysis. The Babel scanner and Semgrep catch the highest-signal JS/TS security patterns, but combined coverage is narrower than what BrassCoders provides for Python.

For mixed-language projects, that's still a meaningful gain. A FastAPI backend with a Next.js frontend gets Python findings from the full scanner set and JS/TS findings from the Babel scanner and Semgrep — all in one .brass/ai_instructions.yaml file, one scan pass, no per-language toolchain stitching required.

To scan any project:

pip install brasscoders
brasscoders scan /path/to/your/project

BrassCoders detects file types automatically. JS/TS findings land in .brass/ai_instructions.yaml alongside Python ones, tagged by scanner name so your AI assistant can triage them in context.

AI Coding Assistant Vendor Risk: What Your Security Team Should Ask

CopperSunDev — Sat, 08 Aug 2026 00:20:32 +0000

Security teams evaluating AI coding assistants tend to collapse two distinct risks into one vendor conversation. The result: a thorough review of the vendor's privacy policy and a gap on the security of what the AI actually produces. Getting both right requires different question sets — one for the assistant's data practices, one for the code it generates.

One surface is the data-handling layer: what the vendor does with your source code during a session, whether that code feeds model training, and what deployment options exist for regulated environments. The other is the code-output layer: what the AI generates and what security issues that code contains before it reaches your repository.

Both surfaces require scrutiny. Conflating them leaves one unexamined.

Two Surfaces, Two Question Sets

BrassCoders addresses the code-output layer (the security issues in the code the AI assistant produces). The vendor risk checklist below addresses the data-handling layer: what the vendor does with your code during and after a session. These are different surfaces, and the questions don't overlap.

Most security evaluations focus on the data-handling layer because it comes with documentation. The vendor has a privacy page, a data-processing agreement, and often a commercial buyer FAQ. That documentation is readable and auditable before you commit to a contract.

The code-output surface has no policy page. It has a finding rate: how often the AI generates code with security issues before those issues land in your repository. CISA's Guidelines for Secure AI System Development, published in November 2023 and co-signed by cybersecurity agencies from the US, UK, Canada, Australia, and New Zealand, explicitly calls for static analysis in the build pipeline for AI-generated code. That call applies regardless of which AI assistant produced the suggestion.

A security team that reviews only the vendor's privacy page has evaluated one surface. The sections below cover the vendor's data-handling surface. The final section covers the code-output surface and what BrassCoders does there.

Questions About Code Transmission

BrassCoders's OSS core sends zero bytes off the machine during a scan. The findings YAML writes locally, and no source code or scanner data leaves the developer's machine in the free tier. For AI coding assistants, the transmission picture differs by design: the product's core function requires sending code to a vendor server to generate a suggestion.

The questions to ask:

Does the assistant send my full source file to vendor servers, or only the context window around the current edit?
Is there an on-machine or offline mode where suggestion generation happens locally?
What does the vendor retain from code sent during a session, and for how long?
Does a data-processing agreement cover code transmission, or only account data and telemetry?

The answers vary significantly by vendor and often by pricing tier. Some assistants transmit the active file plus open files in the same project. Others transmit a narrower window. Retention periods range from session-only to several months. Before deploying to any environment with regulatory or contractual data-handling obligations, confirm the actual data flow against a DPA that covers it.

One distinction worth pressing on: a standard terms-of-service agreement and a data-processing agreement are not the same document. A ToS governs the vendor relationship; a DPA governs how data processed on your behalf is handled. If the vendor doesn't offer a DPA, or the DPA doesn't explicitly cover code sent during suggestion generation, the data-handling obligations for that code may fall outside any contractual protection — even if the privacy policy sounds reassuring.

Questions About Training Data Opt-Out

BrassCoders does not use customer scan data for model training. BrassCoders Paid sends already-redacted findings and a project signature of at most 7,500 characters of non-sensitive metadata to the enrichment gateway. Raw source code never leaves the machine, which means there is no source code available to include in any training corpus.

For AI coding assistants, the training question is distinct from the transmission question. A vendor may retain code only for session purposes and still use it to improve the model. The questions:

Can my code be used for model training, and is opt-out the default or must I request it explicitly?
Does the opt-out apply to fine-tuning as well as pretraining?
Does the opt-out apply on all subscription tiers, or only on higher-tier plans?
Does the opt-out apply retroactively to code already transmitted, or only to future sessions?

Default opt-in to training is common at entry-level price points. Commercial contracts often carry different data-handling terms than the standard user agreement. Teams working on proprietary or regulated codebases should confirm which terms govern their specific tier — and verify that the commercial buyer FAQ describes their actual agreement, not a representative scenario — before any code reaches the vendor's servers.

Questions About On-Premises and Offline Options

BrassCoders's --offline flag provides hard enforcement: brasscoders --offline scan exits non-zero if any network call is attempted at runtime. The zero-transmission guarantee is testable in CI, not just stated in a policy document.

For air-gapped environments and organizations with strict data residency requirements, the deployment model is often the first evaluation gate. The questions:

Is an on-premises deployment available, and does it require a separate license or a different pricing tier?
Is there an air-gapped option that makes zero outbound network calls during inference?
For cloud deployments, which data residency regions are available, and is regional selection standard or an add-on?
What model serving happens server-side, and what computation runs client-side during a suggestion?

Cloud-only vendors with no offline option may not meet FedRAMP requirements or industry frameworks that place conditions on where data processing occurs. The NIST AI RMF GOVERN function asks organizations to document AI system limitations — and a deployment model that rules out regulated environments is a limitation. Get the deployment answer before other evaluation criteria apply.

Questions About the AI-Generated Code Output

BrassCoders covers the code-output layer — the Python and TypeScript files the AI assistant produces that enter your repository — with 12 scanners, running entirely on the local machine.

Most vendor evaluations stop before reaching this question. The vendor's privacy page describes what the vendor does with your code. It does not describe what security bugs that code contains. The questions to ask:

Does the vendor run static analysis on generated code before surfacing it as a suggestion?
What categories of security issues does the vendor's internal tooling check for?
Has the vendor published a finding rate for security bugs in AI-generated code?

For context on what an independent finding rate looks like: the BrassCoders published benchmark covered 15 real Python files from public AI-generated code repositories. BrassCoders caught issues in 9 of the 15 files, covering 11 of 12 bug categories the study examined. Zero proactive security warnings were issued during code generation by the AI assistants that produced those files. That benchmark represents one corpus. The question for any vendor: do they publish a comparable number, and against what test set?

Finding rates that are not published cannot be evaluated. If a vendor has no published number, the follow-up question is whether they run any independent third-party security testing on generated code — and whether those results are available to customers under contract. A vendor with no answer to either question has given you useful information about how they treat the code-output surface.

How BrassCoders Addresses the Code-Output Layer

BrassCoders runs 12 scanners against the code the AI produces — the part no AI vendor's internal tooling reviews before the suggestion lands in your editor, since the suggestion displays before any commit-time gate runs.

The upstream scanners are Bandit, Pylint, Pyre/Pysa, Semgrep, ast-grep, and detect-secrets — the foundational tools for Python security analysis, code quality, taint flow, cross-language pattern matching, and credential exposure. Each is a mature open-source project with documented coverage.

The custom layer adds six more detectors: secret patterns, PII handling, phantom-API call detection for AI-generated imports that don't exist, performance issues, content moderation, and JavaScript/TypeScript.

The JavaScript/TypeScript scanner uses Babel AST parsing and covers .js, .jsx, .ts, .tsx, .mjs, and .cjs files.

Caught patterns include eval() calls, innerHTML XSS sinks, document.write usage, hardcoded API keys, and hardcoded passwords.

The OSS core is Apache 2.0 licensed, requires no account, and sends nothing off-machine. Install with pip install brasscoders and run brasscoders scan .. Output writes to .brass/ai_instructions.yaml. Add brasscoders scan to your CI pipeline to gate every commit — a critical finding returns non-zero and blocks the merge.

For stricter data environments, brasscoders --offline scan enforces zero network calls at the scanner level. The offline guarantee is enforced in code, not in policy.

The vendor risk questions in the sections above address the AI coding assistant's data practices: what they do with your code on their servers. BrassCoders gates on what the assistant actually produces: what the generated code contains once it's back in your repository. These checks operate at different points in the workflow, against different surfaces, with different failure modes.

Run both. Neither substitutes for the other.

The Trust Boundary Problem in AI-Generated Code

CopperSunDev — Fri, 07 Aug 2026 23:44:38 +0000

The prompt said: "fetch this config from the API and use it to initialize the service." The AI generated code that calls the API, parses the JSON, and passes the values directly to initialization. No validation. The code works correctly on valid API responses — which is what every test scenario covered. It fails, in a security-relevant way, when the API returns values an attacker can influence.

The problem isn't a missing code pattern. It's a missing design decision: which sources are trusted, and what validation happens when data crosses from untrusted to trusted?

What a Trust Boundary Is

A trust boundary is the line between parts of a system where data is verified and parts where it isn't. BrassCoders can flag structural indicators that a boundary is missing — user-controlled input in a SQL query, a user-supplied path in a file operation — because those have recognizable shapes. What it cannot determine is whether data from an external API response, a configuration endpoint, or a deserialized payload is being treated as trusted at the right point in the call chain. That's a design question, not a pattern question.

CWE-501 (Trust Boundary Violation) from MITRE defines the category: "the product mixes trusted and untrusted data in the same data structure or structured variable." The violation happens at the boundary crossing — the moment untrusted data enters code that treats it as verified — and that crossing is often invisible in the source because the data looks like any other local variable once it's been assigned.

How AI Assistants Misplace the Boundary

AI-generated code works on the happy path. BrassCoders's published N=15 AI-code-findings corpus found real security issues in 9 of 15 AI-generated Python files — all from neutral prompts, none from prompts that requested vulnerable code. The trust boundary failures in that class don't appear as structural bugs; they appear as code that correctly processes inputs the developer controls and silently trusts inputs an attacker can influence.

An AI assistant generating an HTTP client that fetches external configuration was shown: make the request, parse the response, use the data. The model fills in the code path it was prompted for. Validation of the response fields belongs at the boundary — before parsing, or immediately after — but the prompt described the interior of the function, not the seam where untrusted data enters. The model produces internally correct code with an externally wrong trust assumption.

This is why the trust boundary problem persists even when teams use AI assistants for security review. An AI asked to review a function's code often finds the function well-formed. The trust boundary question is about the function's context: what are the provenance guarantees on its inputs, and does the caller enforce them? That's architectural reasoning, not code reading.

Three Ways the Boundary Fails in AI Code

BrassCoders scans the code that results from trust boundary design decisions — catching the SQL injection and the path traversal where they exist — but the three design patterns that produce trust boundary failures in AI-generated code leave no structural marker: external responses treated as structured data, configuration values passed without verification, and sanitized-flag drift across function calls.

External API responses treated as structured data. An AI-generated integration layer fetches a vendor API response, parses the JSON, and passes the parsed values to downstream functions. The downstream functions trust their inputs. When the vendor API returns unexpected values — or when an attacker influences the response through a misconfigured or compromised upstream — the downstream functions execute on data they assumed was already validated. The code path is correct; the trust assumption is wrong.

Configuration values passed without verification. Environment variables and configuration files sit at a trust boundary. They're not direct user input, but they're writable by anyone with deployment access, and AI-generated code that reads config values and passes them directly to subprocess calls, file path construction, or query parameters skips the validation the boundary requires. The AI was shown: read the value, use the value. The step between — verify the value — was in the design, not the prompt.

Sanitized-flag drift across function calls. AI-generated code commonly applies validation in one function and passes the result to a second that has no knowledge of whether validation happened. Three function calls later, the original source is invisible in the local variable name. The OWASP Testing Guide on input validation identifies this as a primary failure mode: validation happened, but at the wrong layer, and the data's untrusted origin is no longer visible at the point of use.

What BrassCoders Catches Near Trust Boundaries

BrassCoders flags the structural indicators that trust boundaries are missing or misplaced. SQL injection findings (Bandit B608) mark places where user-supplied data flows into a query without parameterization. Command injection findings (Bandit B602/B603) mark subprocess calls where user-supplied strings reach the shell. The phantom-import scanner catches external package references that don't exist — a trust assumption about the package ecosystem that wasn't verified.

Pyre/Pysa, the taint analyzer BrassCoders runs, handles some taint tracking across function boundaries — tracing data from sources to security-sensitive sinks. Its coverage depends on annotated entry points and sink functions for the specific application. What no scanner in the set can determine: whether the data in a config_value variable came from a trusted internal store or an external API response. The variable name doesn't carry provenance, and provenance is the trust question.

What Enforces the Boundary

Trust boundaries are enforced at design time and tested at runtime — BrassCoders clears the structural findings from the code, and the trust boundary architecture lives in a threat model that predates the code.

Enforcing a trust boundary requires identifying the source, defining the validation contract at the entry point, and verifying that the contract holds in integration tests. An external API response gets schema validation before its values are used — not inside the downstream function, but at the seam where untrusted data enters the system. That seam is the boundary. An allowlist on redirect targets enforces a boundary against open redirect payloads. A type assertion before the subprocess call enforces a boundary against command injection. Each of those is a design decision before it's a line of code.

OWASP A04:2021 (Insecure Design) names the class: design-level flaws, including missing trust boundary controls, are distinct from implementation bugs and require design-level fixes. No additional scanning changes a design that assumed external data was safe. The fix is the schema validation at the seam, the allowlist on the redirect target, the type assertion before the subprocess call — in the architecture, before the code is written.

pip install brasscoders
brasscoders --offline scan /path/to/your/project

BrassCoders catches the injection bug where user input hit the query string. The trust boundary that let external config values reach a subprocess call without validation is the design decision — the one the threat model has to make before the code exists, and the test suite has to verify after it's written.