Reported operating use · Software engineering and security
AI vulnerability repair: Google example
Google describes Project Fortify as connecting vulnerability discovery, runtime-aware triage and automated patch preparation. A fixer validates proposed changes in a sandbox and submits a reviewable changelist. Engineers review and merge, and SRE teams monitor canary deployment.
Find vulnerabilities and prepare verified patches for human review
Reported internal use; deployment coverage is not quantified in the account.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Find flaws and prepare reviewable repairs
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Investigation
Vulnerability discovery and runtime triage
Project Fortify connects discovery with runtime-aware investigation.
- Fixer
Sandbox validation and changelist
A fixer prepares and validates proposed patches before submitting reviewable changes.
- People
Engineer review and SRE canaries
Engineers review and merge; SRE teams monitor canaries and product teams set system priorities.
What the source reports
Google describes Project Fortify connecting vulnerability discovery, runtime-aware triage and automated patch preparation. A fixer validates proposed changes in a sandbox and submits a reviewable changelist. Engineers review and merge changes; SRE teams monitor canary deployment. Product teams retain control over precision and recall priorities for their systems.
Reported technology: Google; Gemini scanning harnesses and CodeMender. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Prepare a security repair with independent evidence
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Fictional application and seeded flaw
Pin source, dependencies, affected runtime and protected expected behavior.
- 2 · Preparation and agent contributions
Agent investigates and suggests a patch
Attach reproducer, affected-code references and sandbox test results.
- 3 · Independent checks
Independent reviewer tests defect and regression
Reproduce the original flaw, challenge false positives and check legitimate behavior after repair.
- 4 · People decide acceptance
Maintainer and operations owner decide
Review patch evidence; any release decision is separately authorized.
A reviewable evidence package
A candidate patch with reproducible exploitability and regression evidence.
If a check fails → withhold acceptance.
The patch suppresses a test without fixing the flaw. Reject it and retain the unresolved finding.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. Disposable execution only; the patch cannot approve its own verification or reach production.
- Systems and evidence
- Proposed: use a fictional application, versioned source, dependency records and an isolated runtime containing known defects. Provide test results and affected-code references with each finding.
- People and agents
- Proposed: agents investigate and suggest repairs. A security reviewer verifies exploitability, a maintainer reviews the patch, and an operations owner approves a separate release.
- State and permissions
- Proposed: pin each finding and patch to a source revision. Restrict execution to disposable environments and record test evidence, rejected proposals and unresolved risks.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Proposed: investigate a seeded software flaw and prepare a patch with reproducible evidence for independent review.
Review gate: An independent reviewer reproduces the original defect, verifies the repaired behavior and confirms that release authority remains separate.
Challenge the result: A patch suppresses the failing test without removing the defect. The reviewer must reject it and retain the unresolved finding.
What needs checking
- Proposed: reproduce each seeded defect before repair and verify that the patch removes it without breaking required behavior.
- Proposed: include plausible false positives and require evidence before accepting an exploitable-vulnerability claim.
- Proposed: ensure a patch cannot approve its own verification or reach production through the practice environment.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
How an enterprise could build similar work
A proposed build order for an enterprise doing similar work, written by Nuvepro from the published account and our interpretation of the environment and checks above. It is not how Google built or operates this work.
- Set up a fictional applicationThis is a proposed design for a similar project, not Google's systems. Use a fictional application, versioned source, dependency records and an isolated runtime containing known defects, with test results and affected-code references for each finding.
- Separate agents from reviewersAgents investigate and suggest repairs. A security reviewer verifies exploitability, a maintainer reviews the patch, and an operations owner approves a separate release. No single role covers the whole path from finding to production.
- Pin findings to revisionsPin each finding and patch to a source revision. Restrict execution to disposable environments and record test evidence, rejected proposals and unresolved risks, so nothing disappears from the history of the exercise.
- Reproduce before repairingReproduce each seeded defect before any repair, then verify the patch removes it without breaking required behaviour. Include plausible false positives and require evidence before accepting any exploitable-vulnerability claim, so the exercise rewards verified findings and not confident assertions.
- Block self-approval and releaseEnsure a patch cannot approve its own verification or reach production through the practice environment. Verification and release authority stay with people who are separate from the agent that proposed the change.
- Test a suppressed failureInclude a patch that suppresses the failing test without removing the defect. The independent reviewer must reject it and retain the unresolved finding, after reproducing the original defect and confirming the repaired behaviour.
Your systems, data, rules and accountable owners decide the real project. Agree acceptance criteria, escalation owners and operating responsibility with the people accountable for the work before anything runs on live records. Treat the first run as a rehearsal on test records: compare the draft output with an independently prepared answer, and record what the people reviewing it change.
Questions about this example
- What does Google use AI for in Project Fortify?
- Google describes using Gemini scanning harnesses and CodeMender to find vulnerabilities, triage them with runtime awareness and prepare patches. A fixer validates changes in a sandbox and submits a reviewable changelist. Deployment coverage is not quantified in the account.
- Who reviews the patches Google's agents prepare?
- Engineers review and merge changes, and SRE teams monitor canary deployment. Product teams keep control over precision and recall priorities for their systems. A fixer validates changes in a sandbox before submitting them for human review.
- How strong is the evidence for this Google example?
- The evidence class is reported use: Google's own account of internal use, with deployment coverage unquantified. It is not an independent study and gives no complete evaluation corpus, error rate or measured rollout. Continuous assurance on every commit is described as a direction of travel.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not a replica of Google's systems. It would use a fictional application with seeded defects in an isolated runtime, require reproduction before repair, include plausible false positives, and keep patch approval and production release separate from the agent.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- This is Google's account of its own program, not an independent effectiveness study.
- The article does not provide a complete evaluation corpus, error rate or measured rollout coverage.
- Continuous assurance on every commit is described as a direction of travel, not a universally deployed capability.
- The proposed environment and checks are illustrative designs, not an executed Nuvepro demonstration or a replica of Google's systems.
- How Google Does It: Using agents to help find, track, and fix vulnerabilitiesSource publication: 2026-10-26