Product · Finding Catalog
Ten findings that can defend themselves
A deliberately small, signed, versioned rule catalog. Every finding carries its rule version, its evidence, why it got that severity, and how it might be wrong.
The catalog
What the first catalog covers
Ten families. Six of them are provable from one machine's configuration alone; the rest need either an observed window or a team baseline, and say so.
Broad permission granted
An explicit, provable grant of broad filesystem, network, or shell access — read from the declaration, never inferred from behavior.
Sensitive telemetry or foreign exporter
Telemetry configured to leave the machine to a third-party endpoint, enabled explicitly rather than by default.
Unverifiable provenance
An asset whose origin cannot be established. Reported as unverifiable — unapproved requires a
team baseline to exist first.
Unpinned or drifting version
An executable or package reference that can resolve to different code between sessions with no change on the machine.
Plaintext transport or suspicious endpoint
A server reachable over plaintext, or an endpoint in a category worth a second look.
Duplicate or shadow definition
The same asset defined twice, or a project definition silently overriding a global one.
User/project scope conflict
An asset defined at both scopes with different settings, where the effective configuration is not the obvious one.
Organization baseline drift
A machine that has moved away from the approved baseline. Needs a baseline to exist — Phase 2.
Global asset used in only one repository
An asset installed at user scope but observed only within a single repository, suggesting it belongs at project scope.
Not observed in a covered window
An asset that did not run during a window with enough coverage to make that meaningful. Never reported as unused.
Evidence
What every finding has to carry
These fields are not optional metadata. A finding that cannot fill them cannot render, which is a constraint on us rather than a feature for you.
Rule and version
Every finding names the rule and the exact version that produced it, so a change in the catalog is visible rather than mysterious.
Evidence and severity rationale
What was found, and the argument for why it matters at that level. Not a score you have to accept.
False-positive path
How this could be wrong, and what to do about it. Present on every finding.
Preview and rollback
Where a deterministic fix exists, the exact diff and the way back. Where one does not, the finding says so rather than guessing.
Owner and status
Who it belongs to and where it stands, including whether an exception was recorded and by whom.
Verification timestamp
When the fix was confirmed to have worked. Verified is a recorded fact, not an assumption made after applying.
How it works
The catalog comes to you
The direction matters. Rules travel down; your scan does not travel up.
- 01
Download and verify
The signed catalog is fetched and its signature checked. This requires no account and uploads nothing.
- 02
Evaluate locally
Rules run against your local inventory on your machine. KeepRails does not need to see your setup to tell you what is wrong with it.
- 03
Report with evidence
Each finding arrives with its rule version and rationale attached, so it can be argued with rather than only obeyed.
Coverage
What the catalog will not do
The boundaries are design decisions from the product spec, not gaps waiting on a sprint.
No behavioral inference
Rules fire on declarations and resolved configuration. Nothing here guesses intent from traffic.
No scoring of people
Findings attach to assets and machines. There is no developer score, and none is planned.
No blocking
V1 is advisory. Checks do not block merges by default, and nothing is enforced at runtime — KeepRails is never in the tool-call path.
Where it stops
No payloads are read. A tool the collectors cannot defensibly match is counted as unattributable rather than guessed into a category.
Related
Each surface feeds the next: what the scan finds becomes a finding, and a finding becomes a reversible change.
FAQs about Finding Catalog
Why only ten finding families?
Because a catalog earns trust by being right, not by being large. Every rule here fires on a fact the product can prove — an explicit declaration, a resolved conflict, a missing pin. Rules that would need a guess are not in the catalog.
What does every finding include?
Rule identifier and version, the evidence behind it, a severity rationale, a false-positive path, a remediation preview where a deterministic one exists, a rollback, an owner, a status, and a verification timestamp once verified.
What is a false-positive path?
The stated way this finding could be wrong, and what to do about it. A rule that cannot say how it might be wrong does not ship. It is on every finding, not buried in docs.
What does "signed catalog" mean?
The rules are distributed as a signed artifact. Your machine can download and verify the catalog without uploading your scan — the evaluation runs on your side, which is what lets the anonymous audit send nothing.
Why is severity explained instead of just scored?
Because a number is not an argument. A severity you cannot interrogate is a severity you cannot disagree with, and a finding you cannot disagree with is one you will eventually ignore.
Can I change a rule's severity for my team?
Yes, and the adjustment is recorded rather than applied silently. The same is true of exceptions — they are first-class, audited objects, not a dismiss button.
See what your fleet is actually running
The scan runs locally and reports in your terminal. No account, no upload.
keeprails scan