Reported operating use · Software engineering and security
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.
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.
- 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.
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