CURTIS / COMPLIANCE
v1.3.0 LIVE
open-source fintech compliance  ·  v1.3.0

CURTIS COMPLIANCE Block the commit. Cite the clause.

A static regulatory scanner for fintech code. Catches plaintext secrets, non-TLS calls, missing audit logs — at commit time, with the specific HIPAA / SOC2 / PCI-DSS clause the commit would fail.

LicenseMIT FrameworksHIPAA · SOC2 · PCI-DSS Audit trailHash-chained
Live Demo
curtis-test — bash
$ npm install -g @jordannewell/curtis-compliance $ curtis-compliance init --framework pci-dss ✓ Initialized .curtis/compliance.yaml $ echo "stripe_secret = 'sk_live_...'" > pay.ts $ git commit -m "feat: add stripe" ❌ COMMIT BLOCKED no-secrets-in-code → pay.ts:1 → PCI-DSS 3.4 — Render PAN unreadable.
// 01 — flow

From commit to cited audit event.

Curtis sits inside the developer loop. A non-compliant commit never lands. Every check — pass or fail — produces a tamper-evident event in a local hash-chained JSONL log.

STEP 01

PRE-COMMIT

Developer stages a commit. Curtis runs the configured ruleset against the diff and blocks on failure with the specific citation.

STEP 02

PR REVIEW

The same engine runs on a PR via review:pr with a PAT. Comment + commit status posted automatically.

STEP 03

AUDIT EVENT

Every check appends one event to .curtis/audit/YYYY/MM/DD.jsonl. The event's prev_hash is the SHA-256 of the prior canonical JSON.

STEP 04

EVIDENCE EXPORT

Hand the auditor a CSV: curtis-compliance audit export --format csv. RFC-4180 compliant. Filter by date and framework.

// 02 — terminal

See it block a commit in 60 seconds.

Initialize Curtis in a repo, stage a deliberately non-compliant commit, and watch it block with the exact failing clause.

curtis-test — bash
$ npm install -g @jordannewell/curtis-compliance added 1 package in 1.2s $ mkdir curtis-test && cd curtis-test && git init Initialized empty Git repository in /work/curtis-test/.git/ $ curtis-compliance init --framework pci-dss ✓ Initialized .curtis/compliance.yaml ✓ Installed pre-commit hook ✓ Framework: pci-dss (4 rules enabled) $ echo "stripe_secret = 'sk_live_PLACEHOLDER_EXAMPLE_KEY'" > payments.ts $ git add payments.ts $ git commit -m "feat: add stripe payment" ❌ COMMIT BLOCKED — curtis compliance 🔴 no-secrets-in-code Found 1 potential secret(s) in code. Use environment variables. → payments.ts:1 → PCI-DSS 3.4 — Render PAN unreadable wherever it is stored. Disable with TOKEN_HUNT_ALLOW=1 or rule override in .curtis/compliance.yaml. $ curtis-compliance audit verify ✅ Audit chain intact (142 events verified).
// 03 — what it does

Four pillars. No fluff.

Curtis Compliance occupies a spot no other tool sits in — a dev-loop regulatory gate that produces cited, tamper-evident evidence.

01

PRE-COMMIT GATE

Blocks non-compliant commits locally, before they ship. Each failure cites the specific HIPAA / SOC2 / PCI-DSS clause.

02

HASH-CHAINED AUDIT

Every check writes one event to a JSONL log. Each event's prev_hash chains to the prior canonical JSON. Tamper with history, the chain breaks.

03

REAL CITATIONS

HIPAA §164.312, PCI-DSS 3.4, SOC2 CC6.1 — not invented rules. The citation appears in the commit block, the PR comment, and the audit log.

04

SECRET DETECTION

21 patterns across 12 providers: AWS, Stripe, GitHub, OpenAI, Anthropic, Slack, GitLab, PyPI, Figma, Linear, npm, Google. Plus generic password= / PEM blocks.

// 04 — shape

Configurable. Inspectable. Exportable.

One YAML drives the ruleset. One JSONL captures the evidence. One CSV hands it to the auditor.

.curtis/compliance.yaml

framework: pci-dss
blockOnFailure: true
auditTrail: true
skipPatterns:
  - node_modules/**
  - dist/**

rules:
  no-secrets-in-code:   { enabled: true,  blockOnFail: true  }
  tls-only:             { enabled: true,  blockOnFail: false }
  audit-logging:        { enabled: true,  blockOnFail: false }
  encryption-at-rest:   { enabled: true,  blockOnFail: true  }
  input-validation:     { enabled: true,  blockOnFail: false }

Disable any rule with enabled: false. The result reports skip with a clear "Rule disabled in config" message — no silent dropouts.

.curtis/audit/2026/07/2026-07-20.jsonl

// one line per check — pretty-printed here for the docs
{
  "timestamp": "2026-07-20T17:50:41.259Z",
  "event_id": "db8579a6-971f-...",
  "event_type": "compliance_check",
  "framework": "pci-dss",
  "repo": "acme/payments",
  "commit": "abc123",
  "overall_status": "non-compliant",
  "checks": [
    { "requirement": "no-secrets-in-code",
      "status": "fail", "severity": "critical" }
  ],
  "curtis_version": "1.3.0",
  "prev_hash": "a7192de26a7e8c1d4f5b..."
}

Any modification to a historical event breaks the chain. curtis-compliance audit verify detects it and names the line.

// 05 — landscape

Where it sits.

Closest neighbors aren't competitors — they enforce style, scan for secrets, or attest org-wide posture. Curtis is the dev-loop gate that makes the controls those platforms attest to actually true in the code.

Tool Category What Curtis does differently
ESLint, Biome, Nx Style / convention linters Different category. Those enforce style. Curtis enforces regulatory requirements and cites the failing clause.
Gitleaks, TruffleHog Secret scanners Same detection lineage (21 patterns / 12 providers). Curtis wraps each finding in a compliance workflow — every hit is a cited audit failure, not just a regex match.
Vanta, Drata, Secureframe Compliance automation Those manage org-wide posture and collect evidence for auditors. Curtis sits inside the dev loop, preventing violations at commit time before they ship — the thing that makes the controls those platforms attest to actually true in the code.