Integrate Security Review Extension

[jerop]

Problem

Currently, the Gemini CLI action provides general pull request review, but lacks a specialized security-focused pull request review workflow. As security becomes increasingly critical in software development, we need a dedicated security review process that can:

• Automatically analyze code changes for security vulnerabilities
• Provide detailed security-specific feedback with remediation guidance
• Integrate seamlessly into existing PR workflows
• Focus specifically on security concerns rather than general code quality

Solution

Update gemini-review.yml workflow to perform security reviews on pull requests.

• Add extensions input to action.yml: This will allow us to configure the security extension.
• Experiment in a test repository: We will test the security review extension in a separate repository until Improve PR Review Workflow #269 is resolved. This will allow us to work on the extension without impacting the PR review workflow in this repository.
  • Dogfood upstream: We will use the security review extension in a workflow in https://github.com/google-gemini/gemini-cli. This will allow us to test the extension without impacting PR review workflow in this repository.
• Integrate into PR review workflow: Once the extension is stable and issue Improve PR Review Workflow #269 is fixed, we will add the security review step to the main PR review workflow.
• Consolidate Feedback: Investigate how to generate both general and security feedback, then consolidate them to avoid duplication.

This approach will allow us to develop and test the security review functionality in a controlled environment before deploying it to the main repository.

[sethvargo]

This will be easier after we split up the workflows

[sethvargo]

One point: a given user can only have one "review" open at a time. So a separate workflow on the same PR would cause conflicts unless we sequenced them. It might be better to augment the existing prompt. @jerop thoughts?

[evanotero]

One point: a given user can only have one "review" open at a time. So a separate workflow on the same PR would cause conflicts unless we sequenced them. It might be better to augment the existing prompt. @jerop thoughts?

To add data on how this is being implemented, we're building a dedicated "Security Review" extension for Gemini CLI. This extension will contain the main prompt + custom command + mcp servers that will be installed. This will then expose a /security-review command within Gemini CLI.

Therefore, we'd like to support the following:

• Open a pull request in your repository and get an automatic security review.
• Comment @gemini-cli /security-review on an existing pull request to manually trigger a review.

So are the options to (1) add an invocation of /security-review to the existing pr-review workflow (could add an option to enable or disable security review as a config option), or (2) sequence them?

[sethvargo]

The problem with sequencing is that, unless we speed up install times, we're look at 2min per CLI invocation, just for installation.

[8bitmp3]

Just a thought, would it be possible to (also) have /security-review integrated as part a normal PR /review (💡)? This way it's not an optional afterthought (😦🔨) given that many lines of unsecure code is being (vibe) written and pushed to production daily/weekly by less funded teams and orgs, and learning how to do secure app development is not part of many CS courses?

Gemini Flash/Pro and other small/large reasoning models are already good at performing at least top-level fundamental reviews of [insert any major programming language] code based on a simple prompt like, for example:

"You are a security engineer specializing in secure software development, producing well-secure apps, and discovering vulnerabilities (think like OWASP Top-10). Your task here is to perform an indepth review in line with the secure software development framework (SSDF)."

Maybe this could be added as one or two extra sentences to the existing PR review workflow, and users would be able to disable it if they wish? (secure-review would be enabled by default).

WDYT?

@sethvargo @evanotero @jerop @mihaimaruseac

P.S.

• Secure software development courses are not mandatory in computer science at [add name of university here] AFAIK
• Fuzzing is not mandatory (https://github.com/google/oss-fuzz)
• "Writing secure apps" training is not mandatory AFAIK (like OpenSSF's courses https://openssf.org/training/courses/)
• Passing tests != passing vuln checks AFAIK

Check out AIxCC's newly open sourced solutions for finding potentially vulnerable (and exploitable) bugs: https://archive.aicyberchallenge.com , https://github.com/Team-Atlanta/aixcc-afc-atlantis , https://github.com/trailofbits/afc-buttercup , https://github.com/o2lab/afc-crs-all-you-need-is-a-fuzzing-brain

NIST's SSDF https://csrc.nist.gov/Projects/ssdf :

The SSDF practices are organized into four groups:

- Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level and, in some cases, for individual development groups or projects.
- Protect the Software (PS): Protect all components of the software from tampering and unauthorized access.
- Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases.
- Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

⬆️ We can help users automate some parts of 1-4 above.

[jerop]

fyi, updated the issue above as discussed with @CallumHYoung and the rest of the team