Findings
A finding is a claim with evidence.
Every Kelrova finding names its severity, the exact file and lines, the entry point that reaches them, why it matters and what to change. You read the proof before you spend time on the fix.
Refund endpoint trusts the client's amount
- Severity
- Critical, high confidence
- Where
src/routes/refunds.ts:142- Reached from
POST /refunds- Why it matters
- Any caller can refund more than they paid.
- What to change
- Refund the amount on the charge, never the one in the request.
Evidence
Read the claim, then the proof: all on one page.
Kelrova is an AI security scanner, and each finding it reports opens with its title and severity, then the proof from your code: the file, the marked line and the entry point that reaches it. Below that come the impact and how to fix and test it.
A drawing of a finding page on a sample project, Refund endpoint trusts the client's amount, scrolled to its proof: how to fix it, the location src/routes/refunds.ts:142 with the entry point POST /refunds and high confidence, then four lines of src/routes/refunds.ts with line 142 marked.
Title and severity
One sentence that states the problem, ranked Critical, High, Medium, Low or Info, with how confident the scan is.
Evidence
The file and the lines from your repository, the line that matters marked.
Location and entry point
Where the code lives and where a request comes in. An Adversary finding lists every step of its attack path.
Impact
What an attacker gains, with an example attack scenario. Adversary findings say who is affected: one user, one tenant or all users.
How to fix
The change to make and how to test it, ready for a pull request or for your own hands.
Activity
Fixes, re-checks and reports from connected apps, in order, on the finding itself.
Go Fix
Fix it from the finding: a pull request or your own agent.
Go Fix is the fix button on every finding. When a member asks, Kelrova opens an AI-assisted fix as a draft pull request on GitHub, GitLab or Bitbucket, linked to the finding. Or hand the finding to your AI coding agent through Kelrova's MCP server and fix it in your own checkout.
Fix it now
A member starts the fix, adds instructions if they like, and gets a draft pull request with the change. Your merge gates can review it before it merges.
Your agent, over MCP
Connect your own agent once. It finds the project for your repository, reads the finding, fixes it in your checkout and reports back.
By hand
Every finding says how to fix it and how to test the fix. Copy it as JSON for any tool you work with.
MCP server
https://mcp.kelrova.com/mcp- list_findings
- Lists a project's findings, most severe first, by status, severity, tag or path.
- get_finding
- Reads one finding in full: evidence, location, attack path and how to fix it.
- report_finding_action
- Reports a fix or progress, adds a note, or proposes a false positive or accepted risk for a member to review.
- request_recheck
- Asks Kelrova to check the finding again on the scanned branch once the fix is merged.
Sign in once in your browser and choose what the agent may do. Every plan includes it.
Merge gates
Reviewed before it merges: a fix waits until its reviews pass.
Merge gates are reviews a pull request must pass before it merges. Your organization owner sets them up: Security Review, Code Review and up to 10 of your own. Turn on Review security fixes for a gate and Go Fix pull requests wait for its approval, with any rejection sent back to the fix.
A fix opens a pull request
Each gate with Review security fixes on reviews it, then again on every new version: a fix round, a push or a branch update.
Each gate reviews the change
The verdict follows what the review finds, never a judgement call.
CriticalHighreject the changeMediumLoware shown, never block
A rejection goes back to the fix
A required gate's findings become the next fix round on the same pull request, up to two rounds. After that, reply to the fix yourself or override.
Merge opens
Once every required gate approves the latest version, the pull request can be merged from Kelrova.
- Required or advisory
- A required gate must approve before the merge. An advisory gate shows its findings and blocks nothing.
- Review security fixes
- Go Fix pull requests skip every gate unless you turn this on for the gates that should review them.
- Overrides on record
- Members with the Override merge gates permission can merge anyway with a written reason, and the override is recorded.
- Set by the owner
- Everyone in the organization can see the gates; only the owner can change them.
Re-check
Fixed is checked, not assumed: the next scan looks again.
A finding turns fixed when a scan no longer sees the problem, or when your agent reports the fix. Either way, the next scan checks it again. Once a fix is merged, a re-check looks at that one finding without waiting.
A drawing of a finding's Activity: Webhook signature compared with ==, reported fixed via a connected app with PR #421 on main, then Re-check, Succeeded: fixed on main. Beside it another finding, Verbose error body leaks stack traces, with a proposal waiting for review: accepted risk, with Accept and Dismiss.
Re-check one finding
Checks the finding again against the latest code on the scanned branch, with no pull request. Start it from Go Fix, or from your agent once the fix is merged.
Reopens if it is still there
A later scan that still sees the problem reopens the finding, so fixed means the code changed.
Closing waits for a member
False positive and accepted risk start as proposals. A project member accepts or dismisses them; once accepted, later scans stop reporting the finding as new.
Duplicates and tags
One problem, one finding: repeats are flagged, tags group the rest.
A new finding that looks like one you already have is marked Possible duplicate and linked to it. A member merges the two or keeps them separate, and tags sort the rest by area.
A drawing of a findings list on a sample project, each row tagged API or Auth; the top row, Webhook signature check is not constant-time, is marked Possible duplicate. Beside it that finding's page: May be the same as Webhook signature compared with ==, with Merge and Keep separate, and its tag API, set by scan.
Possible duplicates
- Merge keeps one finding and hides the other from the list; its history stays.
- Keep them separate when they are two problems.
- Review a scan's possible duplicates in one pass, and undo a merge later if you need to.
Tags
- Each new finding gets the tag that fits it best, such as API, Web app or Auth.
- Your members set up to 15 tags per project and can change a finding's tag.
- Filter the list by tag, or ask your agent for one tag's findings.
Access and audit
Findings stay with the project: only its members see them.
Only the members of a project can open its findings. AI coding agents sign in through OAuth with the member's own permissions, and every change to a finding is on record.
- Who sees findings
- Members of the project. Viewers read, Contributors run scans and work on findings, Maintainers manage settings and access. Organization owners and admins always have access.
- Who closes them
- Members who manage findings accept or dismiss proposals, close a finding as a false positive or an accepted risk, and reopen it. An agent can report a fix, but only proposes the rest.
- Connected agents
- Sign in through OAuth in your browser and approve what the agent may do: view findings, report progress, request re-checks. It acts with your own live access, limited to the projects you pick, and you can revoke it under Settings, Connected apps.
- In transit
- Connections to Kelrova use TLS.
- Where scans run
- In Kelrova Cloud, in an isolated runtime. Nothing needs to stay switched on at your end.
- On record
- The project's Activity lists scans, status changes, tags, merges, fixes and pull requests with who did what and when. The organization's Audit Log records changes to members, access, projects, integrations and billing.
Start with one scan: findings with proof and a fix.
Every plan includes Go Fix pull requests, re-checks and the MCP server. Basic starts with a 14-day trial on your first organization.