HIPAA and SOC 2 Teams Can't Use Cloud Code Review

The question for regulated engineering teams isn’t whether to review AI-generated code. It’s whether the review tool itself creates a compliance gap. Cloud-API code reviewers do — and the gap is specific enough to name.

When GitHub Copilot’s review feature, CodeRabbit, or any LLM-based PR review service analyzes your code, it transmits that code to a third-party endpoint. For teams building healthcare software, that single fact triggers two compliance questions: does this transmission require a Business Associate Agreement under HIPAA, and does this vendor relationship expand your SOC 2 audit scope? The answers are usually uncomfortable.

BrassCoders’s OSS core, installed with pip install brasscoders, makes zero outbound network calls. That sentence is the answer. Everything below explains why the problem is real and what the setup looks like in practice.

What Cloud Code Review Means for HIPAA

A cloud-API code reviewer transmits your source code to a third-party endpoint on every invocation, creating a potential Business Associate Agreement problem under HIPAA’s Security Rule (45 CFR § 164.312). BrassCoders’s OSS core makes zero outbound network calls — the --offline flag enforces this at runtime — so the transmission risk doesn’t arise.

The Security Rule text is published by HHS at hhs.gov/hipaa. The challenge for healthcare software teams is that source code doesn’t need to be a medical record to trigger the concern. A developer who’s written a FHIR integration, a patient-lookup function, or a data migration knows that ePHI can surface in unexpected places — hardcoded in a test fixture, embedded in a SQL string literal, sitting in a stack trace someone pasted into a comment. If any of those land in a file sent to a cloud review endpoint, the vendor may have received ePHI without a BAA in place.

HIPAA requires a Business Associate Agreement with any vendor that handles ePHI. Most AI code review vendors either don’t offer BAAs for code-review features specifically or exclude those features from BAA coverage in their terms. GitHub’s documentation, for example, explicitly states that Copilot features process code you transmit; whether and how their BAA covers code-review invocations requires your legal team to verify against current terms. The burden of that verification sits with your team — on every vendor, on every product update.

Running a scanner that never transmits your source code cuts the problem at the root. No transmission, no BAA gap to evaluate.

SOC 2 and the Scope Question

SOC 2 Type II auditors ask which systems have access to your source code — and every external service your CI pipeline transmits code to is a potential scope expansion under the AICPA Trust Services Criteria (CC6 and CC9). BrassCoders’s OSS core, run with brasscoders --offline scan, introduces no vendor relationship to assess for source code access.

The AICPA publishes the Trust Services Criteria framework at aicpa-cima.com. Adding a cloud code reviewer to your CI pipeline means adding a vendor to your SOC 2 vendor assessment process. You document the vendor, describe the data flow, assess their controls, and revisit the assessment on whatever cadence your auditor requires. If the vendor updates their architecture or terms, the assessment may need to be redone. This isn’t theoretical friction — teams preparing for SOC 2 Type II audits regularly discover that their tool choices have silently accumulated scope they weren’t tracking.

The --offline flag enforces zero egress at runtime: it returns a non-zero exit code if any network call is attempted. That behavior is auditable — your CI logs show the exit code, not an assumption.

The Practical Test: What Leaves the Machine

BrassCoders’s OSS core scan — brasscoders --offline scan — analyzes your project locally and writes findings to .brass/ with directory permissions 0700 and file permissions 0600. Nothing leaves the machine. The Paid plan ($12/month) sends only already-redacted findings and a project signature of up to 7,500 characters from non-sensitive metadata (README, dependency manifest, top-level filenames) to BrassCoders’s hosted gateway — never raw source code.

The comparison with cloud API reviewers is direct:

Tool	What Leaves the Machine	BAA Required?
GitHub Copilot code review	Full diff / source	Check vendor terms
CodeRabbit	Full diff / source	Check vendor terms
BrassCoders OSS (--offline)	Nothing	No
BrassCoders Paid	Redacted findings + project signature	Evaluate per your posture

The “check vendor terms” entries in that table are not placeholders. They reflect the actual situation: vendor terms change, BAA coverage for specific features is often scoped differently than BAA coverage for the product overall, and the determination requires legal review against current documentation. Teams that assumed coverage and later discovered the exclusions have had to unwind integrations mid-audit. The safest path is one where the question doesn’t arise.

Setting Up BrassCoders in a Regulated CI Environment

For teams with strict egress controls, BrassCoders’s OSS core with the --offline flag is the recommended CI setup. The flag is a hard requirement, not a default — it actively rejects any configuration that would initiate a network call, so a misconfigured Paid-plan integration can’t silently transmit data. The build fails instead, loudly, with a non-zero exit code.

A GitHub Actions step looks like this:

- name: Run BrassCoders scan
  run: |
    pip install brasscoders
    brasscoders --offline scan .

For GitLab CI:

brasscoders-scan:
  script:
    - pip install brasscoders
    - brasscoders --offline scan .
  artifacts:
    paths:
      - .brass/
    expire_in: 30 days

The artifacts block in the GitLab example is worth noting. The .brass/ directory contains YAML findings that your security team can review, archive, or feed into a SIEM. Uploading them as a CI artifact keeps them inside your CI environment — they’re attached to the build, not transmitted to a third party. Your auditor gets a timestamped artifact tied to each commit. That’s a better evidence trail than a cloud reviewer’s audit log, which lives on the vendor’s infrastructure.

The expire_in value is yours to set based on your retention policy. BrassCoders doesn’t impose one.

What BrassCoders Catches That Matters for Healthcare Code

BrassCoders’s privacy and secret detectors are directly relevant to healthcare codebases. BrassCoders detects 20+ hardcoded secret formats — AWS access keys, GitHub PATs, OpenAI API keys, Stripe live keys, Slack tokens, JWTs, and PEM-encoded private keys — using Yelp’s detect-secrets as the upstream library plus custom patterns added in the scanner layer.

The detect-secrets library from Yelp uses entropy analysis alongside explicit regex patterns to catch credentials that pure-regex scanners miss. The privacy/PII scanner identifies patterns common in healthcare code: names, Social Security numbers, phone numbers, and email addresses appearing in string literals and test fixtures. This catches the case where a developer copies a real patient record into a fixture file to reproduce a parsing bug — a pattern that’s more common than anyone on the team wants to admit.

Bandit covers the OWASP-mapped security rules — SQL injection sinks, insecure hash functions, TLS misconfiguration — that matter in any production backend but carry additional weight in healthcare systems subject to breach notification requirements. The full 12-scanner stack (Bandit, Pylint, Pyre/Pysa, Semgrep, ast-grep, detect-secrets, and six custom detectors) runs entirely as local processes with no outbound calls. A typical scan against a mid-size Python service takes under 30 seconds. The findings land in .brass/ as YAML structured for direct consumption by Claude Code, Cursor, or any AI assistant that reads files. Your developer sees the finding; no third-party cloud service touched the code to produce it.

For a regulated team, the right question isn’t whether to scan AI-generated code. It’s whether the scanner itself passes your vendor review.

---

Install with pip install brasscoders and run brasscoders --offline scan /path/to/project. The findings go to .brass/. Nothing else moves. Questions about deployment patterns or the Paid plan’s data handling: brass@coppersuncreative.com.

For the broader picture on what AI code review tools transmit, see What BrassCoders Sends to Its Servers (And What It Doesn’t).