Skip to content

Integrations

Kelrova connects where your code already lives.

Link repositories from GitHub, GitLab or Bitbucket and Kelrova scans them in the cloud. Findings come back in the portal, by email and to your own agent through the MCP server.

Get startedConnect your agent
A diagram: code sources from GitHub, GitLab and Bitbucket, each on its tracked branch, go into a scan in Kelrova Cloud. Findings come out to the portal, to email and to your own agent through the MCP server.

Code sources

Pick the repositories: Kelrova scans the branch you choose.

Link your GitHub, GitLab or Bitbucket account, then add each repository you want reviewed for vulnerabilities, with the branch to scan.

  • GitHub

    GitHub App

    OrganizationPersonal account

    Link as many GitHub accounts as you need. Each Kelrova organization sees only the repositories it picked.

    First time

    1. Install the GitHub App on an organization or personal account.
    2. Choose the repositories to link; you must administer each one.
    3. Add the repository to a project and pick the branch to scan.

    Fixes open as draft pull requests

  • GitLab

    GitLab.com

    GroupPersonal namespace

    Link a GitLab.com group where you are a Maintainer or above, or your personal namespace.

    First time

    1. Sign in to GitLab.com and approve Kelrova.
    2. Pick a group or your own namespace, then its repositories.
    3. Add the repository to a project and pick the branch to scan.

    Fixes open as draft merge requests

  • Bitbucket

    Bitbucket Cloud

    Workspace

    Link a Bitbucket Cloud workspace you administer, or one where you are a repository admin.

    First time

    1. Sign in to Bitbucket Cloud and approve Kelrova.
    2. Pick a workspace, then its repositories.
    3. Add the repository to a project and pick the branch to scan.

    Fixes open as draft pull requests

Good to know

  • An owner or admin links each account once, under Connections.
  • Only GitLab.com and Bitbucket Cloud. Self-managed GitLab and Bitbucket Data Center are not supported.
  • Kelrova changes code in a repository only through a pull request a member asks it to open. On GitLab and Bitbucket, linking a repository also adds a webhook so pull request status stays current.

What linking does

  • ReadsOnly the repositories you pick
  • ScansThe branch you pick for each repository
  • SkipsFolders you exclude
  • WritesRequested pull requests; a webhook on GitLab and Bitbucket

MCP server

Findings where you fix them: in your own agent.

AI coding agents and editors that speak MCP can read a project's findings and act on them: fix one in your checkout, report the fix back and ask for a re-check. The server is part of every plan.

  1. Add https://mcp.kelrova.com/mcp to your client's MCP settings.
  2. Your browser opens once: sign in, then pick the organization and projects.
  3. Grant viewing only, or reports and re-checks too.
  4. Revoke any connection under Settings → Connected apps.
mcp.json : MCP client settings with Kelrova added
{  "mcpServers": {    "kelrova": {      "type": "http",      "url": "https://mcp.kelrova.com/mcp"    }  }}

A drawing of the consent screen the first call opens: the organization, all projects, the three permissions it asks for, and Allow access.

Six tools

Every connection offers the same six. What an agent may change follows the access you granted when you connected it.

list_projectsView
Finds the Kelrova project for the repository you are in, from its git remote.
list_findingsView
Lists a project's findings, most severe first, by status, severity, kind, tag or path.
get_findingView
Reads one finding in full: evidence, location, attack path and a link to its page.
get_finding_activityView
Shows what happened to a finding, from reports to runs started in the portal.
report_finding_actionReport
Reports a fix or progress, adds a note, or proposes closing a finding for review.
request_recheckRe-check
Asks Kelrova to check one finding again on the scanned branch.

A typical loop

The server's fix_security_findings prompt hands an agent these steps in one message.

  1. Listlist_findingsThe open findings of the project you are in.
  2. Readget_findingOne finding in full, with its evidence.
  3. FixIn your checkoutMake the change, then run the project's tests.
  4. Report fixedreport_finding_actionWith the commit or pull request and a short note.
  5. Re-checkrequest_recheckOnce the fix is merged to the scanned branch.

A finding reported fixed is marked fixed at once. The next scan or a re-check confirms it, and reopens it if the problem is still there.

CI and automation

No browser in CI: a machine client acts for a member.

An owner or admin creates one for a job that cannot sign in. It holds only the access and projects you give it.

Created by
An owner or admin, under Organization → MCP server
Runs as
A member you choose, and sees only what they can
Access
Viewing findings, plus reports and re-checks if you tick them
Projects
All projects, or up to 200 you select
Credential
A public key, a JWKS URL or a client secret
Tokens
Valid for 15 minutes; the job requests a new one
Expires
After 30, 90 or 180 days, or one year

Email

Results by email: when a scan finishes, with what it found.

Nobody has to watch a run to hear how it went. Subjects never name the project or a finding.

  • A scan finishesWhoever started it, or manages its schedule, gets the result.
  • With what it foundCounts by severity, new and recurring, and up to ten linked findings.
  • A scheduled scan cannot startYou hear why, and what to check before the next run.
  • Each member decidesSwitch these off in Settings → Notifications, or unsubscribe in one click.
A drawing of the email a finished scan sends: the subject "Scan finished: 5 new findings", the scan of northwind/payments-api, its findings counted by severity, and each new finding with a link to its page.

Link a repository: then run your first scan.

Get startedRead the docs