# The Gemini CLI Security extension reviews your diffs with /security:analyze

> gemini-cli-extensions/security is Google's Apache 2.0 licensed Gemini CLI extension that adds a security review command for code changes plus a dependency scan backed by OSV-Scanner. It is a first-pass analysis in an interactive session, not a substitute for an audit.

**gemini-cli-extensions/security** — Google's Security extension for the Gemini CLI that finds vulnerabilities in your code changes and pull requests.

- Repository: https://github.com/gemini-cli-extensions/security
- Stars: 794 · Forks: 59
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/gemini-cli-extensions-security

## A security review command added to Gemini CLI

The Security extension is an open-source Gemini CLI extension whose stated purpose is to enhance a repository's security posture. It adds a command to Gemini CLI that analyzes code changes to identify a variety of security risks and vulnerabilities.

The audience is developers and reviewers who want a second opinion on a diff while they are already working inside the CLI. The feature list is explicit about the focus: analysis is specifically designed around code changes within pull requests, so the tool looks at what changed rather than at the whole repository. That is a narrower target than a full audit and a much cheaper one, since a pull request diff is the part of the code most likely to carry a new bug.

The extension is developed by Google as part of the gemini-cli-extensions organisation and is distributed under the Apache 2.0 licence. The README also describes the architecture as extensible, with room for future expansion of the detected risk classes and more advanced analysis techniques.

The repository layout matches that framing. There are commands, a skills directory, an mcp-server directory, a gemini-extension.json manifest, docs, and the usual project files including CHANGELOG.md, CONTRIBUTING.md, SECURITY.md and a GEMINI.md file. The presence of release-please configuration and a release-please manifest shows releases are automated from conventional commits.

## The analysis scope defaults to a merge-base diff

The mechanism behind the review is a git diff, and the default scope is a specific one. By default the /security:analyze command determines the scope of the analysis using git diff --merge-base origin/HEAD, which means it compares the current branch against the merge base with the remote default branch.

That default is sensible for the common pull request case, because it captures the commits on the branch rather than the divergence introduced by unrelated upstream commits. It also has a consequence worth stating: if your team rebases, merges or otherwise updates the base branch inside the working tree, the diff you get is not the diff the reviewer sees on the pull request.

The scope can be changed, and the method is unusual. Instead of a flag for the diff range, you add natural language instructions to the command. The README's example asks it to analyse all the source code under a scripts folder and to skip docs, config and package files:

```bash
/security:analyze Analyze all the source code under the script folder. Skip the docs, config files and package files.
```

This is a deliberate design choice with a real downside. It is fast to write and does not require learning a second query language, but it is not deterministic, so the scope you actually get depends on how the model interprets the instruction. There is no documented flag to pin the analysis to an exact commit range.

Output format is handled separately. The report can be requested as JSON with the --json flag, or by asking for it in natural language:

```bash
/security:analyze --json
```

That matters for automation, since a JSON report can be parsed by a script while a prose report cannot.

## Dependency scanning is OSV-Scanner with a friendlier wrapper

The second command is a separate concern from the model-based review. /security:scan-deps automates dependency scanning by integrating OSV-Scanner, which cross-references a project's dependencies with OSV.dev, described in the README as a Google-maintained open-source vulnerability database that aggregates information from a wide range of open-source ecosystems.

The command is simply:

```bash
/security:scan-deps
```

The report lists which dependencies are vulnerable, details about each vulnerability including its severity and identifiers, and remediation guidance such as which version to upgrade to. That output structure is the deterministic part of the extension: the vulnerability matching comes from a database with identifiers and severity labels, not from a judgement call by the model.

It is worth being clear about the division of labour, because the two commands are often treated as one feature. The dependency scan finds known vulnerabilities in packages you already depend on. The analysis command looks for security risks in the code you changed, including risks that have no advisory and therefore no database entry. Neither covers the other.

The practical consequence for CI is that a pipeline using both commands gets two different kinds of signal with different confidence levels, and the second is the one that needs a human reading it.

## Installing the extension and running it once

Installation is a single command from a terminal, and the README states a version requirement of Gemini CLI v0.4.0 or newer:

```bash
gemini extensions install https://github.com/gemini-cli-extensions/security
```

The extension is installed from the GitHub URL rather than from a registry, so the source repository is the thing you are trusting, and there is no separate package index in between.

The first real use is a single slash command in an interactive Gemini CLI session:

```bash
/security:analyze
```

It analyses the code changes on the current branch and returns a security report aimed at improving the repository's posture. There is one constraint that matters and it is stated plainly in the README: the command is currently designed for interactive use, and support for non-interactive sessions is planned for a future release, tracked as issue 20 in the issue tracker.

That limit is the one to check before you build anything around it. A CI job that shells out to the command and expects a machine-readable answer will not work today, which is exactly why the --json flag exists but non-interactive invocation does not.

The README also asks that the report be treated as a first-pass analysis rather than a complete security audit, and recommends combining it with other tools and manual review. That framing is the right one to carry into your own process.

## Pull request review through a run-gemini-cli workflow

The extension ships a GitHub Actions workflow so the review can run on pull requests instead of only in a developer's terminal. The README splits the instructions by whether you already use the run-gemini-cli workflows from the google-github-actions organisation.

If you do, the instruction is to replace your existing gemini-review.yml with the updated workflow in this repository, which includes the new security analysis step. If you do not, the steps are to follow the quick start in the run-gemini-cli documentation, create a.github/workflows directory if it does not exist, copy the example workflow from the repository into it, adjust it using the run-gemini-cli configuration reference, commit and push the file, and then open a pull request.

Once the workflow is in place, the trigger is a comment on the pull request. Commenting @gemini-cli /review runs the Gemini CLI code review along with the security analysis, so the security pass travels with the review rather than as a separate step someone has to remember.

The repository also holds the assets referenced from the README, including a workflow diagram for the extension. Keeping the workflow in the extension repository, rather than only in the run-gemini-cli documentation, is what makes the integration copy-pasteable for teams that have never used that action before.

The trade-off is that the review now runs in CI, where a finding is a comment on a pull request rather than a conversation. The README does not describe how findings are routed, filtered or dismissed, which is the part you will want to design yourself.

## What the 90 percent precision benchmark actually measured

The README publishes an evaluation, and it is worth reading the method rather than the headline. The dataset is the OpenSSF CVE Benchmark, a collection of GitHub repositories of real applications written in TypeScript or JavaScript, where each vulnerability comes with the commit that introduced it and the commit that fixed it.

For each entry, the extension's setup found the introducing patch with the help of archeogit, applied that patch to a local environment, ran /security:analyze on the diff to generate a report, and then compared the report against the ground truth. The evaluation yielded a precision of 90 percent and a recall of 93 percent.

The methodology section contains the caveat that matters: since the dataset has a small number of repositories, all the generated reports were reviewed manually to calculate the final numbers. The README also says the team is working to automate the evaluation framework and to enrich the datasets with new classes of vulnerability.

So the figures describe a manual evaluation over a small, JavaScript and TypeScript only sample of known CVEs, on diffs that introduce a vulnerability. They do not measure how the extension behaves on a large real pull request, on a codebase with unusual idioms, or on vulnerability classes that were not in the dataset. Reading the number as a general accuracy claim for production review would be a mistake; reading it as evidence that the approach detects known vulnerability patterns in mainstream web code is fair.

The release history gives the context for how new this is. Versions 0.3.0, 0.4.0 and 0.5.0 were published on 2025-10-20, 2025-12-17 and 2026-04-01, and the last push was on 2026-07-25, so the numbers describe a version that is still moving.

## Running OSV-Scanner and deterministic analysers yourself

There is a meaningful alternative for the dependency half of this tool, and it is the tool the extension itself wraps. Running OSV-Scanner directly against your lockfile gives you the same database matching with a standalone binary, a stable output format and no dependency on Gemini CLI being installed or authenticated. If dependency scanning is your main goal, the wrapper adds a chat interface rather than a capability.

For the code-change half, the alternative is the deterministic static analyser you already run in linting or CI, which checks for known-bad patterns on every commit without a model in the loop. The difference in approach is the trade you are making. A rule-based analyser gives the same answer for the same diff every time, produces no false positives from misreading context, and costs nothing per run. An extension like this one can reason about intent, about whether a value reaching a sink is actually attacker controlled, and about the combination of several otherwise innocuous changes, which rules cannot do.

The failure modes are mirror images. The model-based pass can miss a real issue and can also raise findings that a human dismisses, which is why the README frames it as a first-pass analysis to be combined with other tools and manual review.

A sensible combination is deterministic scanning on every commit, the extension's analysis on pull requests where a human is present to argue with the findings, and OSV-Scanner on a schedule for dependencies that change outside your pull requests.

## Conclusion

Adopt the Gemini CLI Security extension if your team already runs Gemini CLI and wants a security pass on the diff of a pull request without leaving the terminal or the pull request comment. Do not treat it as a compliance gate on its own, because the README calls the report a first-pass analysis and the command currently works only in interactive sessions. Verify first that Gemini CLI is at version 0.4.0 or newer, confirm your repository's diff base matches the default merge-base behaviour, and read the dependency scan output separately since it comes from OSV-Scanner rather than from the model. The last push was on 2026-07-25.

## FAQ

### How do I install the Gemini CLI Security extension?

Run gemini extensions install https://github.com/gemini-cli-extensions/security from a terminal. The README states that Gemini CLI v0.4.0 or newer is required.

### What does /security:analyze actually look at?

By default it determines the analysis scope with git diff --merge-base origin/HEAD, so it covers the changes on the current branch. You can widen or narrow that scope by adding natural language instructions to the command, for example to analyse all the source code under a scripts folder.

### Can I run the Gemini CLI Security extension in CI?

The GitHub integration is documented: copy the example workflow into .github/workflows and comment @gemini-cli /review on a pull request to run the review with the security analysis. The /security:analyze command itself is currently designed for interactive use, with non-interactive support tracked in issue 20.

### What does /security:scan-deps check?

It integrates OSV-Scanner, which cross-references your project's dependencies with the OSV.dev vulnerability database. The report lists which dependencies are vulnerable, the severity and identifiers of each issue, and guidance such as which version to upgrade to.

### How accurate is the Gemini CLI Security extension?

The README reports a precision of 90 percent and a recall of 93 percent on the OpenSSF CVE Benchmark, a dataset of real TypeScript and JavaScript applications. The evaluation was done manually over a small number of repositories, and the README says the team is working to automate it and add new vulnerability classes.

## Sources

- [gemini-cli-extensions/security on GitHub](https://github.com/gemini-cli-extensions/security)
- [Issues](https://github.com/gemini-cli-extensions/security/issues)
- [License: Apache-2.0](https://github.com/gemini-cli-extensions/security/blob/main/LICENSE)
- [README](https://github.com/gemini-cli-extensions/security/blob/main/README.md)
- [Releases](https://github.com/gemini-cli-extensions/security/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gemini-cli-extensions-security