{"slug": "onboarding-developers-to-ai-assisted-workflows-with-security-built-in", "title": "Onboarding Developers to AI-Assisted Workflows With Security Built In", "summary": "BrassCoders, a security scanner designed to catch what AI assistants structurally miss, integrates into developer workflows through three checkpoints: a local CLI install, a pre-commit hook, and a CI gate. The tool ensures consistent scanning from day one, with no outbound network calls and an Apache 2.0 license. BrassCoders ships on PyPI and requires Python 3.10 or later.", "body_md": "Most security tooling gets bolted on after the first incident. A new hire joins, writes a few AI-assisted PRs, and three months later someone notices a hardcoded key in the commit history.\n\nBrassCoders, the scanner that catches what AI assistants structurally miss, changes that timeline. The three-step baseline — install, pre-commit hook, CI gate — can be in place before a new developer pushes their first commit. From that point forward, every developer on the team works with the same scanner, the same output format, and the same noise level. Day one and day one hundred look identical.\n\nBrassCoders integrates into a new developer's environment through three distinct checkpoints: a local CLI install, a pre-commit hook that runs before code leaves the machine, and a CI gate that catches anything that slips through. Each layer is independent — you can adopt all three or start with one — but together they create a security baseline that new developers inherit automatically.\n\nThe YAML output format is identical at every layer. A finding that shows up in a local scan looks exactly the same in the pre-commit hook output and in the CI job log. There's no translation step, no different severity scale per layer, and no findings that only appear in CI.\n\nBrassCoders ships on PyPI as `brasscoders`\n\nand requires Python 3.10 or later. The install is a single command.\n\n```\npip install brasscoders\n```\n\nmacOS ships with Python 3.9 as the system default on many machines. Verify your version before installing:\n\n```\npython3 --version\n```\n\nIf it reports 3.9 or below, use your actual 3.10+ executable explicitly:\n\n```\npython3.12 -m pip install brasscoders\n```\n\nFor team consistency, pin this in a `requirements-dev.txt`\n\nor add `brasscoders>=2.0.10`\n\nto your dev dependencies in `pyproject.toml`\n\n. Every developer gets the same version. Onboarding becomes a `pip install -r requirements-dev.txt`\n\nand nothing else.\n\nOnce installed, run a scan against any Python project:\n\n```\nbrasscoders scan /path/to/project\n```\n\nThe default scan makes zero outbound network calls. No API key, no account, no telemetry. Apache 2.0 licensed. The `--offline`\n\nflag makes that explicit if you want it spelled out in CI scripts.\n\nBrassCoders plugs into the pre-commit framework — a tool used by Python projects everywhere to enforce linting, formatting, and import sorting before code reaches version control. Adding BrassCoders follows the same pattern as any other pre-commit hook: one entry in `.pre-commit-config.yaml`\n\n.\n\nThe pre-commit framework lives at [pre-commit.com](https://pre-commit.com). The full BrassCoders setup is documented in the [pre-commit hook guide](https://coppersun.dev/blog/pre-commit-hook-ai-coder-bugs/). The short version: add BrassCoders to your `.pre-commit-config.yaml`\n\n, run `pre-commit install`\n\n, and every `git commit`\n\nfrom that point forward runs the scanner against staged changes.\n\n```\nrepos:\n  - repo: local\n    hooks:\n      - id: brasscoders\n        name: BrassCoders security scan\n        entry: brasscoders scan\n        language: system\n        types: [python]\n        pass_filenames: false\n```\n\nWhat this gives a new developer: their first `git commit`\n\nruns the scanner. Not when they open a PR. Not when the CI job fires. Before the code leaves their machine. If they're writing AI-assisted code and a phantom API call or a hardcoded secret slips in, they see it in their terminal at commit time — while the context is still fresh.\n\nPre-commit hooks are local by default. Each developer installs them once per clone with `pre-commit install`\n\n. Include that step in your onboarding docs.\n\nBrassCoders runs as a CI step that catches what the pre-commit hook missed — developers who skipped hook installation, branches created before the hook existed, or direct pushes that bypassed the hook entirely. The CI gate is the backstop.\n\nBrassCoders runs cleanly in any CI environment that has Python 3.10+. The full integration instructions are available for [GitHub Actions](https://coppersun.dev/blog/add-brasscoders-to-github-actions/) and [GitLab CI](https://coppersun.dev/blog/add-brasscoders-to-gitlab-ci/). Both integrations follow the same pattern: install the CLI, run `brasscoders scan`\n\n, fail on findings above a severity threshold.\n\nGitHub Actions snippet:\n\n```\n- name: Install BrassCoders\n  run: pip install brasscoders\n\n- name: Run BrassCoders scan\n  run: brasscoders scan . --offline\n```\n\nGitHub Actions documentation describes the `pip install`\n\nstep as a standard setup action in Python workflows — the same `setup-python`\n\n+ `pip install`\n\npattern used in Python CI applies here without modification.\n\nThe CI scan and the local scan produce the same YAML. A developer who saw a finding in the pre-commit hook will recognize the same finding format in the CI log. That consistency matters: they already know how to read it.\n\nBrassCoders runs 12 static-analysis scanners against every scan and emits a single unified YAML report. A new developer sees the same scanner coverage as a veteran — no configuration required, no onboarding-specific mode.\n\nSix upstream scanners handle the foundation: Bandit, Pylint, Pyre/Pysa, Semgrep, ast-grep, and detect-secrets.\n\nSix custom detectors extend coverage to secrets, PII, phantom-API calls, performance, content moderation, and JS/TS.\n\nA new developer clones the repo and runs `pre-commit install`\n\nafter the dev dependency install. Their first `git commit`\n\ntriggers the scanner immediately. The output is a YAML block: each finding names the file, line, scanner, and severity level, plus a `how_to_read_this_file`\n\nguide at the top that explains the format for both human readers and AI assistants.\n\nThat last part is the point. The YAML output is structured for Claude Code or Cursor to read directly. The new developer pastes the finding into their AI assistant's context window, and the assistant explains whether the finding is a real bug, a false positive, and how to fix it. BrassCoders generates the report. The AI assistant handles the triage. Neither job bleeds into the other.\n\nA developer who joins the team on day 100 sees the same output as a developer who joined on day one. The format doesn't change as the product evolves; the scanner doesn't add a new scoring system each sprint; the YAML structure is versioned and stable.\n\nBrassCoders releases scanner updates to PyPI as new AI coding patterns emerge. AI assistants introduce new phantom-API patterns and new secret formats arrive as SaaS vendors add key prefixes — the threat model shifts faster than a static scanner install can track.\n\nKeeping the version pinned in `requirements-dev.txt`\n\nand updating it on a regular cycle (monthly works for most teams) pulls in new scanner patterns without requiring any configuration changes. The output format stays compatible across minor versions — findings from an older version look structurally identical to findings from a newer one.\n\nThe [team consistency post](https://coppersun.dev/blog/vibe-coding-team-consistency/) covers the argument for a shared scanner version across a team in more depth. The short version: drift between developer scanner versions means different developers see different findings. One developer's pre-commit hook passes a finding; another developer's doesn't. The CI gate catches the difference, but it's better to surface it locally. Pin the version.\n\n```\npip install brasscoders\nbrasscoders scan .\n```\n\nThat's the starting point. Add the pre-commit hook before the first PR. Add the CI gate before the first merge to main. The baseline is in place before a new developer has had a chance to ship a finding.\n\nApache 2.0, zero outbound calls in OSS mode, Python 3.10+. No account required to start.", "url": "https://wpnews.pro/news/onboarding-developers-to-ai-assisted-workflows-with-security-built-in", "canonical_source": "https://dev.to/coppersundev/onboarding-developers-to-ai-assisted-workflows-with-security-built-in-3p3p", "published_at": "2026-07-22 17:14:04+00:00", "updated_at": "2026-07-22 17:31:28.499090+00:00", "lang": "en", "topics": ["developer-tools", "ai-safety"], "entities": ["BrassCoders", "PyPI", "Apache 2.0", "GitHub Actions"], "alternates": {"html": "https://wpnews.pro/news/onboarding-developers-to-ai-assisted-workflows-with-security-built-in", "markdown": "https://wpnews.pro/news/onboarding-developers-to-ai-assisted-workflows-with-security-built-in.md", "text": "https://wpnews.pro/news/onboarding-developers-to-ai-assisted-workflows-with-security-built-in.txt", "jsonld": "https://wpnews.pro/news/onboarding-developers-to-ai-assisted-workflows-with-security-built-in.jsonld"}}