Inspect a repository

unveilr .

Runs detectors over a repository and reports findings — secrets, prompt injection, command and SQL injection, path traversal, PII — each with a stable rule ID, a severity, and the message that explains it.

$ unveilr . --fail-on high
1 finding(s) across 12 file(s) scanned under . (risk score 40/100):

  CRITICAL SEC-AWS  AWS access key id
           handler.py

Flags

Flag	Effect
--json	Machine-readable output
--fail-on <tier>	Exit non-zero at or above this severity. info, low, medium, high, critical, none. Default critical.

Gating CI

- name: AI-SDLC findings
  run: unveilr . --fail-on high

--fail-on is the whole integration: the exit code is the gate. Choose the threshold deliberately — critical (the default) is quiet enough to adopt without a backlog triage, high is where most teams end up once they have cleared the initial findings.

Rule identifiers, honestly

There are two identifier schemes in the project right now, and they do not agree:

• The shipped detector implements 11 rules under SEC-AWS, PI-001, CI-002 and similar, in internal/scanner/detect/detect.go.
• docs/findings/catalog.yaml documents 29 rules under UVR-XXXX IDs.

The catalogue is the target shape, not the shipped one. Neither the ID format nor the coverage match yet.

If you are building automation, branch on what the binary currently emits, and expect the identifiers to change before 1.0 — schemas are v1alpha1 precisely so this kind of change is expected rather than breaking a promise. See Findings.