Code Index & CVE Exposure ​

A new CVE drops. Two questions matter right away: which of the releases running right now are on an affected version, and does your code actually call the vulnerable function? Bumpkit answers both. Then it opens the fix pull request for you.

Beta, early access. A workspace without access gets 403 FEATURE_EARLY_ACCESS and a link to request it.

Upload a code index ​

A code index is the index.scip file a SCIP indexer writes for one commit. Bumpkit keeps only the symbols and references it derives from the index, never your source, and keeps the newest 50 indexes per repository.

Run the indexer for your language in the repository root, on the commit you build, then upload the file:

bumpkit index upload index.scip

--commit defaults to HEAD and --repository to the origin remote. From an AI agent, the index_upload MCP tool does the same.

scip-go ​

For Go modules. Install scip-go from its release page, then run it in the module root.

scip-go
bumpkit index upload index.scip

scip-typescript ​

For TypeScript and JavaScript projects. Install your dependencies first so the indexer can resolve imports.

npm install -g @sourcegraph/scip-typescript
scip-typescript index
bumpkit index upload index.scip

scip-java ​

For Java, Kotlin and Scala builds with Maven, Gradle or sbt.

scip-java index
bumpkit index upload index.scip

scip-python ​

For Python projects. Install your dependencies into the active environment first.

npm install -g @sourcegraph/scip-python
scip-python index . --project-name=your-project
bumpkit index upload index.scip

GitHub Actions ​

Upload an index on every push to your default branch and every pull request, after the step that builds and installs your indexer:

- name: Index the code
  run: scip-go
- name: Upload the index
  run: bumpkit index upload index.scip
  env:
    BUMPKIT_API_KEY: ${{ secrets.BUMPKIT_API_KEY }}

What reachability shows ​

When a release check finds a dependency with a known vulnerability, and the advisory names the affected functions, Bumpkit searches the code index for that commit:

• Reachable (cve_reachable): your code calls the affected function. The finding shows the call path from the entry point to the vulnerable function, with the file and line of every hop.
• Not reachable (cve_unreachable): none of the functions in the index reach it. The finding says how many functions and references were searched.
• Reachability not measured: either no code index was uploaded for the commit, or the advisory names no affected functions. The finding says which one and what to do.

You see the same result in the release check, the blast radius on the web, bumpkit blast-radius and the blast_radius MCP tool. Put cve_reachable in gate.block_on to block high and critical vulnerabilities your code reaches:

gate:
  block_on: [cve_reachable]

CVE exposure ​

Look up any OSV, CVE or GHSA id to see every live release and environment whose dependencies include an affected version:

bumpkit cve exposure CVE-2024-45337

On the web, open Releases and pick the CVE exposure tab. From an AI agent, use the cve_exposure MCP tool.

The result leads with a verdict: Exposed with how many releases run an affected package, Not exposed with how many live releases were checked, or Not checked with the reason. Owners and admins can open the fix pull request from the verdict. The CLI prints the verdict first, and the API and the cve_exposure MCP tool return it as verdict.

Below the verdict, Bumpkit shows the advisory as OSV publishes it:

• The severity, with the CVSS score, level and vector. Bumpkit scores CVSS 4.0 and 3.x vectors and prefers the newest version OSV lists.
• When the advisory was published and last modified.
• The full description, CWE ids and aliases.
• Every affected package with its affected version ranges and fixed versions, such as golang.org/x/crypto: fixed in v0.31.0.
• Every affected repository OSV tracks by commit, such as go.googlesource.com/crypto: fixed in commit b4f1988. Each commit links to the exact commit on GitHub, GitLab or googlesource; the CLI prints the commit URL.
• References grouped as Advisory, Fix, Report and Web.

Anything OSV doesn't provide is left out.

A CVE record often lists only the fixing commit. Bumpkit follows its GHSA and Go advisory aliases and uses their package ranges, so looking up a CVE id matches the same releases as its GHSA or GO id. When aliases disagree, the range with an explicit fixed or last affected version wins; between two explicit ranges, the ecosystem's own database wins (the Go vulnerability database for Go, GitHub advisories for everything else). Bumpkit never widens a range beyond what an advisory states.

For each live release, Bumpkit shows:

• The repository, environment, deployed commit and version, from your deploy events.
• The affected package, the installed version and the smallest fixed version.
• Where the dependency list came from: the code index for the deployed commit when you uploaded one, otherwise the repository's lockfiles and manifests at the deployed commit.
• Whether that release's code reaches the vulnerable function, with the call path, when a code index exists for the deployed commit.

A live release Bumpkit can't prove is on an exact version is listed as Not checked with the reason and what to upload: a version range with no lockfile, manifests from a different commit than the one deployed, a development-only dependency, or no dependency data at all. It is never hidden, and it never counts as exposed.

Bumpkit learns what's live from deploy events. Until your workspace has recorded a deploy, exposure says so and links to Record deploys.

Open the fix pull request ​

Owners and admins can open the fix from the exposure view, or with:

bumpkit cve fix CVE-2024-45337 --repository acme/api

The cve_fix MCP tool does the same. Bumpkit picks the smallest version that leaves every affected range, edits your manifest, lists anything it can't change mechanically as a TODO, and opens the pull request through the GitHub App. Bumpkit's release check runs on the pull request as soon as it opens, like on any other. Bumpkit never merges it: review it, finish the TODOs and merge it yourself. Running the fix again returns the pull request that is already open.

Vulnerability alerts ​

You don't have to look up a CVE to find out you're exposed. Bumpkit watches newly published and updated advisories and checks each one against every live release in your workspace, every 10 minutes. When one affects a release you ship, you hear about it within minutes.

What triggers an alert ​

An alert fires only when Bumpkit can prove a live release ships an affected version:

• Exact package. The ecosystem and name match exactly: the Go module path including any /v2 suffix, the npm name including its scope, the normalized PyPI name. The same name in another ecosystem never matches.
• Exact version. The installed version comes from the code index for the deployed commit, a lockfile, or a pinned version in the manifests at the deployed commit. Ranges with no lockfile, manifests from another commit, and development or optional dependencies show as Not checked on the exposure tab and never alert.
• Inside the affected range. Versions are compared with the ecosystem's own rules, semver for Go, npm and crates.io and PEP 440 for PyPI, including pre-releases and the advisory's exact bounds.
• Used. When a Go advisory names the affected packages and the code index shows the release never imports them, the release shows as Present but not used and doesn't alert.

Bumpkit reads exact versions from these lockfiles: package-lock.json, yarn.lock, pnpm-lock.yaml and bun.lock for npm; poetry.lock, uv.lock, Pipfile.lock and pdm.lock for Python; gradle.lockfile for Gradle; packages.lock.json for .NET; Cargo.lock, Gemfile.lock, composer.lock, mix.lock, pubspec.lock and Podfile.lock. poetry.lock, uv.lock, pdm.lock and Pipfile.lock can list packages that only install on some platforms, so a match found only in one of them shows on the exposure tab as Not checked with the matched version and never alerts. Upload a code index for the deployed commit to check those releases.

Severity comes from the advisory and reachability from your code index, never guessed. A withdrawn advisory never alerts, and an alert already sent is retracted with a follow-up message.

Where alerts go ​

Each match is reported once per release, with the same wording everywhere: in the inbox, in Slack (your Slack App channel, or your Slack webhook) and by email to owners and admins. The message gives the severity, the advisory id, each affected release and environment with the installed and fixed versions, whether your code reaches the affected function with the call path, and a link to the exposure tab. A reachable critical or high advisory also opens an incident. You're alerted again only when the severity rises or another release becomes affected.

Newly published advisories apply to release checks right away, so a pull request that adds an affected version is flagged on its next check. Put cve_reachable in gate.block_on, or set vulnerabilities in your policy, to block on them.

Settings ​

With automatic fixes on, Bumpkit opens the smallest upgrade out of the affected range as a pull request, exactly like bumpkit cve fix. The release check runs on it, and Bumpkit never merges it.

Owners and admins change these on the web under Settings, or with:

bumpkit settings set --vulnerability-alerts reachable --auto-fix-prs critical_high

The settings_set MCP tool and PATCH /v1/settings take vulnerability_alerts and auto_fix_prs. Every change is recorded in your workspace audit log.

Recent alerts ​

bumpkit cve alerts

On the web, the CVE exposure tab lists recent alerts. From an AI agent, use the cve_alerts MCP tool.

API ​

Each endpoint is rate limited per API key, and every upload and fix is recorded in your workspace audit log.