Kusari Inspector Runs in GitHub, GitLab, and the CLI

Security review in every pull request.

Reviews the code and dependencies in each pull request, several layers deep, and returns a merge decision and a fix across the repositories you own.

Built on the dependency graph behind Kusari, from the team that co-created GUAC and SLSA.
Kusari Inspector's review comment on a pull request: a green Proceed with these changes verdict, no flagged issues detected, and all values within acceptable risk parameters, above a blurred paragraph of the underlying dependency and code analysis.
What your teams get

Security review where the code gets written.

Issues get fixed before they merge.

Inspector reviews each pull request inside GitHub, GitLab, and the CLI. Roughly 95% of open source vulnerabilities sit in transitive dependencies, below the package a developer chose.

  • Post the finding in the pull request, so the developer resolves it where they wrote the code.
  • Return the version change that clears the issue at its root, so the fix lands in one commit.
  • Trace transitive dependencies several layers deep, so reviewers see risk they have no practical way to follow by hand.
PR #847 · add checkout retry
feat/checkout-retry → main
Kusari Inspector · Blocked
Code analysis: clean
no secrets or insecure patterns in the changed files
Critical vulnerability, 4 layers deep
minimist@1.2.5 via node-gyp → tar → mkdirp
CVE-2021-44906 9.8 prototype pollution
Fix at the root
-  "node-gyp": "^7.1.2"

+  "node-gyp": "^9.4.0"
2 checks · 1 blocking · 5.4s ▸ kusari/inspector

Engineers spend their time on real findings.

Inspector runs a suite of industry-standard analyzers over the changed files, then reads the surrounding code before a finding posts. At one 6,000-seat health insurer that took 90% of findings off the queue.

  • Run established analyzers per ecosystem, so findings start from real tool output.
  • Follow the callers and the workflows that reach the flagged component, so results that cannot be reached drop out. Enterprise
  • Rank what remains by severity and likelihood of exploit, so the top of the list is the place to start.
kusari cli
kusari ▸ scan --diff main..HEAD
6 analyzers · 42 results · 5 reachable
CRIT minimist@1.2.5 · reached from routes/checkout.ts
WARN tough-cookie@4.1.2 · reached from lib/session.ts
DROP lodash.template@4.5.0 · no calling path
DROP sqlite3@5.0.2 · test fixtures only
37 further results withheld · no calling path in this repository

One security standard holds across every team.

Inspector reads its configuration from your workspace, your GitHub organization, and each repository, with a kusari.yaml file at the repository root taking precedence over all of them.

  • Set the policy at the organization level, so enforcement does not vary by team or by reviewer availability.
  • Fail the check when a pull request breaks policy, so the merge waits on a decision.
  • Route each exception through admin approval, so a suppression is something a person signed off on.
PR #512 · bump ssl-utils to 4.2.0
deps/ssl-utils → main
Kusari Inspector · Blocked
Policy: copyleft license not permitted
ssl-utils@4.2.0 relicensed to AGPL-3.0
rule inherited from the acme-corp organization policy
Exception requested
awaiting admin approval · opened by @app-team
Vulnerabilities: none introduced
0 new findings across 214 transitive dependencies
2 checks · 1 blocking ▸ kusari/inspector
See it yourself

Walk through a real pull request review.

A self-guided tour of transitive dependency findings, the fix in context, and the merge decision, shown the way your developers see it.

"
If you use GitHub and you do not have this for your PR review process, you are just doing it wrong, regardless of your risk appetite. Kusari Inspector gives clear, contextual security checks—right in your pull requests, boom!
Joseph Stein · Principal Data Architect, SS&C Technologies
Coverage

Eliminate entire classes of security issues.

Inspector runs across the changed files and the full dependency graph on each pull request, and enforces your security policy the same way whether a person or a coding agent wrote it.

Known vulnerabilities

Severity, CVSS, and likelihood of exploit across the direct and transitive dependencies in the graph.

Transitive dependencies

The layers below the package a developer changed, several levels deep, with the path that pulled each one in.

Credentials and secrets

API keys, tokens, and credentials caught before they land in your git history.

Typosquatted packages

Dependency names that shadow a real package, including ones a coding agent suggested.

Software licenses

Copyleft and permissiveness categorized per dependency, so license review happens at review time.

Unmaintained components

The security posture of each dependency's own repository, including projects that have gone quiet.

Code weaknesses

Static analysis over the changed files, read against the surrounding code for context.

Pipeline and image config

GitHub workflow, Dockerfile, Terraform, and Helm chart issues, plus unpinned action and container versions.

▸ The sequence

From install to merge decision.

Four stages run on every pull request, in order. Connect once, and the remaining three happen on each change without anyone asking for them.

Stage 01
Connect
Install the app and pick your repositories. Setup takes minutes and needs no agents, no pipeline changes, and no work from your developers.
GitHub App and Action GitLab and CI/CD templates CLI, IDE, and MCP
Stage 02
Analyze
Run the analyzers that fit the change. Inspector selects the industry-standard tools for each ecosystem in the diff and runs them across the changed files and the dependency graph.
Changed files Direct and transitive dependencies Workflow and container config
Stage 03
Verify
Test each finding against the surrounding code. Inspector reads how the flagged component is called and sets aside the results that cannot be reached.
Callers followed Severity in context Unreachable results withheld
Stage 04
Decide
Deliver the verdict and the fix in the pull request. The developer gets a merge decision, the change that resolves the issue, and a thread for follow-up questions.
Merge decision Root-cause fix Questions answered inline
Built to interoperate

Runs where your developers are.

Inspector covers ten ecosystems and installs onto the review your team already runs, so one security standard reaches a polyglot org through the tools each group has chosen.

GitHub App

Reviews pull requests natively and posts the merge decision as a comment.

Setup guide

GitHub Action

Drops into an existing workflow and fails the check on findings when you ask it to.

Setup guide

GitLab

Reviews merge requests inside the code review your team already runs.

Setup guide

CI/CD pipelines

Ready-made templates to add Inspector to a build on the provider you already use.

CI templates

Kusari CLI

Runs the same analysis locally, before a pull request is opened.

Setup guide

IDE and coding agents

Returns findings in the editor and to the agents writing alongside you.

View integrations

MCP server

Gives a coding agent a security check it can call while it works.

View integrations
Supported languages & ecosystems
Go Node.js Python Java .NET Ruby Rust Terraform OpenTofu Docker Helm
Pricing

What Inspector costs.

Solo developers and open source
Free
Covers the repositories you own, plus any project under the OpenSSF or the CNCF.
Inspector for teams
From $25per developer per month
Covers every repository your organization owns. Talk to us about volume pricing and rollout.

To add Inspector Pro to your Kusari Platform subscription, contact your sales representative.

FAQ

How Inspector works in practice.

Does our source code leave our repositories?

Inspector analyzes the changed files and the dependency graph, and does not store your code in any form. Once the analysis finishes, the input is deleted. Data is encrypted in transit and at rest, and Kusari is SOC 2 Type II compliant.

How does Inspector handle a monorepo?

Configuration resolves in order: workspace defaults, then your GitHub organization, then the individual repository, then a kusari.yaml committed at the repository root. A repository that carries its own kusari.yaml uses that file alone, so a service with different requirements can hold its own settings while the rest of the estate stays on the organization policy.

Does Inspector review dependency update pull requests?

Yes. A Dependabot pull request gets the same review as any other change. These are the pull requests where a single version bump moves transitive dependencies several layers down, and the diff a reviewer sees is a version number. Inspector reports what changed underneath it.

How does this fit with Dependabot, CodeQL, and the SCA we already run?

Inspector sits alongside them. Dependabot opens a pull request when a newer version is published, and CodeQL analyzes the code your own team wrote. Inspector reviews the pull request itself: the dependency graph several layers past the manifest, how the flagged component is called in your code, and the version change that resolves the finding at its root. Output from the scanners you already run feeds the Kusari Platform, which is the estate-wide view above all of them.

Can we suppress a finding we have already accepted?

Yes. You can create an exception that suppresses a specific finding while the rest of the analysis stays active, so an accepted risk stops reappearing on every pull request. Exceptions require admin approval before they take effect.

Is there a limit on how large a pull request Inspector will review?

Inspector analyzes pull requests with up to 2,000 total dependency changes, and examines up to 1,000 high-priority dependency changes in depth.

What languages and ecosystems does Inspector cover?

Go (go.mod, go.sum), Node.js (package-lock.json, yarn.lock), Python (requirements.txt, poetry.lock, Pipfile.lock, uv.lock), Java (pom.xml, gradle.lockfile), .NET (.csproj, .vbproj, .fsproj), Ruby (Gemfile.lock), and Rust (Cargo.lock).

Inspector also reads HashiCorp Configuration Language, which covers Terraform and OpenTofu, along with Dockerfiles, GitHub workflow files, and Helm charts.

What is free and what is paid?

The GitHub App is free to install and review your pull requests. Agentic Analysis, SBOM generation, and the estate-wide capabilities of the Kusari Platform are part of a paid plan.