Skip to main content

Findings

Every finding carries a stable rule ID, a severity, and a message explaining it.

The identifier situation, stated plainly​

There are two schemes in the project, and they do not currently agree:

  • Shipped: 11 rules, in internal/scanner/detect/detect.go
  • Documented: 29 rules under UVR-XXXX IDs, in docs/findings/catalog.yaml

The catalogue is the target shape. Neither the ID format nor the coverage matches the binary yet.

This is documented rather than hidden because automation built against the catalogue would break, and finding that out from your CI is worse than reading it here.

What the binary emits today​

IDCategory
SEC-AWSAWS access key id
SEC-GHGitHub token
SEC-PKPrivate key material
PI-001, PI-004Prompt injection
CI-001, CI-002Command injection
PT-001, PT-003Path traversal
PII-EMAILEmail address
PII-SSNUS social security number

Verified against the shipped detector rather than the catalogue.

Severity and gating​

Severities are info, low, medium, high, critical. --fail-on sets the exit-code threshold and defaults to critical. See Inspect.

False positives are validated, not just matched​

A regex can say "this is shaped like PII"; only a validator can say "this is PII". Reserved example domains (RFC 2606) and published test card numbers exist precisely so documentation and fixtures can be written without inventing real data — reporting them is noise that discredits the real findings next to them.

Building automation against this​

  • Branch on the exit code, not on parsed human output.
  • Use --json when you need detail.
  • Expect identifiers to change before 1.0. Schemas are v1alpha1 so that this is an expected change rather than a broken promise.