Google Launches Gemini 3.5 Flash Cyber to Find and Patch Vulnerabilities Faster

Google has introduced Gemini 3.5 Flash Cyber, a specialized AI model designed to find, validate, and patch software vulnerabilities. The lightweight model builds on Gemini 3.5 Flash but receives additional training for cybersecurity work.

Google developed the model for use with CodeMender, its automated code-security agent. CodeMender can scan source code, investigate suspected vulnerabilities, test whether flaws are exploitable, and generate patches for developers to review.

Gemini 3.5 Flash Cyber will not receive a general public release initially. According to the Google DeepMind announcement, selected governments and trusted partners will gain access through a limited CodeMender pilot program soon.

What Is Gemini 3.5 Flash Cyber?

Gemini 3.5 Flash Cyber is a lightweight cybersecurity model fine-tuned for vulnerability discovery and remediation. Google says it offers better performance on these tasks than its general-purpose Gemini Flash models while costing less per token than larger models.

The model targets a major scaling problem in software security. A large codebase may contain millions of lines of code and a vast number of possible execution paths, making deep vulnerability searches expensive and time-consuming.

Instead of relying on one call to a large model, CodeMender can run several Gemini 3.5 Flash Cyber agents. Each agent explores different code paths before the system combines their findings into one report.

Capability	What Gemini 3.5 Flash Cyber does
Vulnerability discovery	Examines source code and explores execution paths for potential security flaws.
Validation	Helps determine whether a suspected flaw creates a genuine security risk.
Exploit testing	Can generate proof-of-concept code for controlled testing in isolated environments.
Patch generation	Creates proposed code changes intended to correct validated vulnerabilities.
Patch testing	Checks whether a proposed fix resolves the flaw without breaking expected behavior.
Parallel analysis	Supports several agents exploring different parts of a codebase before producing a combined report.

Why Google Chose a Smaller Flash Model

Finding deeply hidden vulnerabilities often requires repeated searches rather than a single answer. Every additional model invocation can examine another section of code, test a different theory, or follow another execution path.

Large frontier models may perform well on individual tasks, but repeatedly calling them can increase cost and delay results. Google designed Gemini 3.5 Flash Cyber to make repeated agent calls more practical.

This architecture could support frequent repository scans, security checks before product launches, and commit-level analysis inside development pipelines. It may also allow security systems to spend more computing resources on promising findings.

How CodeMender Uses Multiple Cyber Agents

CodeMender acts as the workflow around the underlying AI models. It supplies security tools, code context, prompts, verification systems, and controlled environments for investigating potential vulnerabilities.

For some tasks, the agent can run Gemini 3.5 Flash Cyber as many as five times before producing one final report. Multiple calls allow the model to explore more possibilities and reduce repeated discoveries of the same issue.

The Google Cloud CodeMender preview describes three main stages: scanning code, verifying exploitability, and generating a tested remediation for developer approval.

1. CodeMender connects to an approved source-code repository.
2. The agent scans the code for memory, injection, cryptographic, web, and data-handling flaws.
3. It investigates whether each suspected issue creates an exploitable condition.
4. Proof-of-concept code runs inside an isolated, customer-managed sandbox.
5. CodeMender generates a proposed patch for confirmed vulnerabilities.
6. The agent tests the change against application behavior and coding requirements.
7. A developer reviews and approves the code difference before committing it.

Gemini 3.5 Flash Cyber Results on CyberGym

Google evaluated Gemini 3.5 Flash Cyber with CyberGym, a security benchmark based on vulnerabilities found in real open-source software. The benchmark tests whether AI agents can navigate repositories and reproduce security problems.

The original CyberGym benchmark contains 1,507 real-world vulnerabilities from 188 open-source projects. It uses executable tests to assess whether an agent can generate a proof of concept that triggers a known flaw.

Google configured CodeMender to call Gemini 3.5 Flash Cyber up to five times for each final report. The company says the resulting agent reached competitive performance against significantly larger cybersecurity models.

Google has not published every numerical result in its announcement. It also notes that competitor results in the comparison came from scores reported by the respective providers rather than one independently controlled evaluation.

Big Sleep Tests Covered Chrome and Safari

Google’s Big Sleep security team created another evaluation focused on difficult vulnerabilities in complex software, including Chrome and Safari. The tests ran without the model’s normal safety guardrails.

Google reports that Gemini 3.5 Flash Cyber significantly outperformed the general-purpose Gemini 3.5 Flash and Gemini 3.6 Flash models on this evaluation.

The company reported results as a pass-at-one success rate, which measures how often the model succeeds on its first attempt. Google did not disclose all evaluation cases or the underlying vulnerabilities, limiting outside reproduction of the complete test.

Chrome Commit Scanning Used Undisclosed Vulnerabilities

Google also tested the model through Chrome’s production commit-scanning pipeline. The evaluation used vulnerabilities that had not been publicly disclosed.

Using undisclosed flaws reduces the risk that the model encountered the answers in its training data. Google says Gemini 3.5 Flash Cyber produced a significant success-rate improvement over the general Gemini 3.5 Flash model.

Google did not include newer competing models in part of the comparison because their safety systems refused the requested tasks. Claude Opus 4.6 appeared in the published V8 comparison.

Gemini Flash Cyber Found 55 Confirmed V8 Issues

In a separate test involving the V8 JavaScript engine, Google ran each model for a fixed number of invocations. Gemini 3.5 Flash Cyber found 55 unique confirmed issues.

Model	Unique confirmed V8 issues
Gemini 3.5 Flash Cyber	55
Gemini 3.5 Flash	47
Claude Opus 4.6	36

Gemini 3.5 Flash Cyber found 10 issues that neither of the other tested models identified. Google says the model continued to find new code paths and issues as the number of invocations increased.

Less capable models may repeatedly return to an issue they already identified. A model that explores more diverse code paths can produce more unique findings from the same number of attempts.

These results come from Google’s internal testing. Independent researchers would need access to the evaluation methods, model, and affected code to reproduce the findings fully.

Google Used the Model on Internal Code

Google says CodeMender already uses Gemini 3.5 Flash Cyber to find and fix vulnerabilities in internal codebases. The listed products and services include Chrome, Android, Google Cloud, Ads, and YouTube.

In one internal test, Google’s Cloud Vulnerability Research team used the model to find remote code execution flaws in public APIs and a memory-corruption issue in a sensitive production service.

Google says the model completed the discovery work within two hours. It then generated an exploit that reliably achieved remote code execution while bypassing Address Space Layout Randomization and Write XOR Execute protections.

The Gemini 3.5 Flash Cyber report describes the exploit as 100% reliable in Google’s test environment. The company has not disclosed technical details about the affected systems or vulnerabilities.

What ASLR and W^X Protections Do

Address Space Layout Randomization, commonly called ASLR, changes where programs and libraries load in memory. This makes it more difficult for an exploit to predict the location of useful code or data.

Write XOR Execute, written as W^X, prevents a memory area from remaining writable and executable at the same time. The protection aims to stop attackers from writing malicious code into memory and then running it directly.

An exploit that bypasses both protections demonstrates advanced vulnerability research capability. It also highlights why Google has limited access to a small group of defensive partners.

Why Google Is Restricting Access

Vulnerability research models have clear defensive uses, but they can also help attackers find exploitable weaknesses. Exploit-generation capabilities create an especially significant dual-use risk.

Google plans to make Gemini 3.5 Flash Cyber available only through CodeMender during the initial pilot. Governments and trusted partners will receive access first, with wider availability considered over time.

The restricted launch aims to give defenders access while reducing the chance of misuse. Google has not announced a public API, general enterprise release date, or consumer availability for the specialized model.

Product or capability	Availability
Gemini 3.5 Flash Cyber	Coming soon through a limited pilot
Eligible Flash Cyber users	Selected governments and trusted partners
CodeMender for enterprise customers	Available in preview using generally available Gemini models
Public Gemini Flash Cyber API	Not announced
Consumer Gemini app access	Not announced

CodeMender Is Entering Enterprise Preview

Google is separately bringing CodeMender’s scanning and remediation capabilities to enterprise customers in preview. Customers can use generally available Gemini models through the Gemini Enterprise Agent Platform.

This enterprise preview does not provide general access to Gemini 3.5 Flash Cyber. Google treats CodeMender with the specialized cyber model as a separate, restricted offering.

CodeMender can connect with continuous integration and delivery pipelines or run through a local command-line client. Google also lists support for VS Code and its Antigravity development environment.

The agent supports C, C++, Go, Java, Python, Ruby, Rust, and TypeScript. It can scan first-party applications, open-source projects, and third-party software when customers grant access to the relevant repositories.

Developers Retain Control Over Generated Patches

CodeMender can create a code difference containing its proposed fix, but Google keeps developers in the approval process. The agent does not need to commit every generated patch automatically.

Developers can review the vulnerability evidence, exploit test, proposed correction, and expected effect on application behavior. They can reject or modify the patch before adding it to the repository.

According to the CodeMender product announcement, the agent also uses an AI-based evaluation step to check whether a fix could disrupt existing functionality.

• Review all AI-generated code before committing it.
• Run existing unit, integration, and security tests.
• Test proof-of-concept exploits only inside isolated environments.
• Check whether the patch introduces new permissions or dependencies.
• Require approval for high-risk and production changes.
• Preserve audit logs for vulnerability and patch decisions.
• Use conventional static analysis and fuzzing alongside AI scanning.

CyberGym Results Need Careful Interpretation

CyberGym measures an important part of AI security performance, but it does not represent every vulnerability class or development environment. A strong benchmark result does not guarantee that a model will find every flaw in production software.

The CyberGym research project focuses on real vulnerabilities and executable proof-of-concept generation. Those tasks remain difficult even for capable agent systems.

Organizations should evaluate detection accuracy, false positives, patch correctness, operating costs, and developer review requirements before integrating an AI security agent into production workflows.

Google Draws on OSV and OSS-Fuzz Data

Google says its security experience provides valuable training and evaluation data. This includes vulnerability records from OSV and more than a decade of software-testing results from OSS-Fuzz.

OSV provides a distributed vulnerability database for open-source software. Its records map vulnerabilities to affected package versions and source-code commits, helping tools identify relevant dependency risks.

Google’s OSS-Fuzz project continuously tests open-source software with fuzzing tools. Fuzzing sends unusual and unexpected inputs into programs to expose crashes, memory errors, and other security problems.

Google reports that OSS-Fuzz has helped identify and fix more than 13,000 vulnerabilities and 50,000 bugs across approximately 1,000 projects. The project supports languages including C, C++, Rust, Go, Python, Java, JavaScript, and Lua.

Training Data Supports Realistic Security Work

Vulnerability databases show models how security flaws affect particular projects and versions. Fuzzing results provide examples of the inputs and program behavior that reveal real software defects.

The Open Source Vulnerabilities database currently contains more than 700,000 records across supported ecosystems. Google says this scale helps its models move beyond small collections of synthetic security examples.

More than ten years of OSS-Fuzz testing data can also expose patterns involving memory corruption, parser errors, crashes, and unsafe input handling.

Google combines this information with security tools and agent workflows that can inspect large repositories. The objective is to teach models to follow processes used by professional vulnerability researchers rather than simply predict vulnerable-looking code.

FAQ